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Abstract 

With  the  increase  of  both  technology  push  and  operational  pull  of  Mini/Micro 
Aerial  Vehicles  (MAVs)  within  DoD  organizations,  an  understanding  of  their  interactions 
and  capabilities  is  necessary.  Many  MAVs  have  been  developed  for  specific  usage 
and  much  speculation  made  on  future  uses.  Despite  their  growth  there  is  currently  no 
overarching  systems  architecture  to  envelop  and  guide  the  DoD’s  MAV  development 
efforts.  The  goal  of  this  thesis  is  to  apply  sound  systems  engineering  principals  to 
develop  a  MAV  architectural  model  describing  their  use  in  three  separate  but  closely 
related  mission  areas:  Over-the-Hill-Reconnaissance,  Battle  Damage  Information  (BDI), 
and  Local  Area  Defense.  This  thesis  focuses  on  single  man-packable/operable  MAVs 
utilized  by  small  ground  units  synonymous  with  special  operations  forces  (SOF).  The  three 
mission  areas  are  combined  to  define  a  single  overarching  Intelligence,  Surveillance,  and 
Reconnaissance  (ISR)  MAV  architecture.  The  architecture  focuses  on  the  current  state  of 
ISR  MAVs  and  baselines  that  AS-IS  capability.  From  this  architecture,  areas  of  interest 
relating  to  MAVs  and  their  use  in  the  DoD  are  discussed,  focusing  on  enhancing  both 
current  and  future  capabilities  of  the  MAV. 
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A  SYSTEMS  ARCHITECTURAL  MODEL  FOR  MAN-PACKABLE/OPERABLE 


INTELLIGENCE,  SURVEILLANCE,  AND  RECONNAISSANCE 
MINI/MICRO  AERIAL  VEHICLES 


I.  Introduction 

Researching  the  topic  of  mini  and  micro  aerial  vehicles  (MAVs)  reveals  extensive 
examples  of  their  application  and  use  already  existing  in  many  organizations  including:  the 
Department  of  Defense  (DoD),  research  organizations,  academic  institutions,  and  private 
industry.  While  the  basic  MAV  concept  has  been  around  as  long  as  model  airplanes,  a 
major  push  for  their  gainful  employment  in  military  operations  occurred  within  the  last 
two  decades.  For  reasons  of  troop  security,  stealth,  hazardous  terrain,  mundane  missions, 
and  vantage  point,  MAVs  have  and  continue  to  prove  themselves  useful.  Many  organi¬ 
zations  have  developed  and  continue  to  develop  MAVs  specific  to  their  set  of  requirements 
or  emerging  technologies.  However,  only  a  handful  were  created  with  the  concept  of 
integration  in  mind,  and  those  that  have  rarely  integrate  beyond  their  specific  organization. 

While  interest  in  MAVs  continues  to  grow,  so  has  the  desire  by  military  planners 
to  seamlessly  incorporate  these  systems  into  Air  Force  missions  where  their  utility  can 
be  fully  realized.  Due  to  the  complexity  of  integrating  individual  MAV  systems  into 
their  the  currently  fielded  family  of  systems  (FoS),  military  leaders  and  system  developers 
require  better  methods  for  defining  MAV  specifications  and  how  they  interact  with  their 
environment.  These  issues  are  addressed  by  the  Air  Force’s  increased  emphasis  on  systems 
engineering  (SE)  and  transformation  to  integrated  architectures  through  use  of  the  DoD 
Architecture  Framework  (DoDAF).  While  the  concept  of  SE  is  not  new,  better  method¬ 
ologies  were  needed  within  the  Air  Force  to  manage  complex  programs  as  evidenced 
when  Secretary  of  the  Air  Force  Roche  stated  “Many  of  our  current  system  acquisition 
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programs  are  suffering  from  a  lack  of  attention  to  or  inconsistent  application  of  good 
systems  engineering  principles”  [30]. 

This  refocus  on  systems  engineering  seeks  to  relate  the  functional,  operational, 
and  systems  viewpoints  together  thus  providing  both  descriptive  and  visual  represen¬ 
tations  of  the  system  under  design.  These  representations  of  a  system  are  referred  to  as 
architectures.  The  DoDAF  is  intended  to  provide  information  on  how  systems  are  related 
to  higher  level  architectures;  an  example  of  which  is  the  C4ISR  (Command,  Control, 
Communications,  Computer,  Intelligence  and  Reconnaissance)  architecture  [9].  The  use 
of  sound  systems  engineering  principles  and  the  development  of  architectures  enables  a 
more  comprehensive  and  effective  development  strategy  for  the  design  of  systems.  An 
integrated  architecture  allows  the  developers  and  users  of  a  system  to  better  plan  for  a 
system’s  requirements.  If  a  strategic  plan  for  the  use  of  MAVs,  as  well  as  the  planning 
and  acquisition  of  future  MAV  capabilities  is  to  be  built,  the  entire  system  must  be  defined 
using  systems  engineering. 

1.1  Thesis  Goal 

The  goal  of  this  thesis  is  to  apply  sound  systems  engineering  principles  to  develop 
an  architectural  model  describing  the  use  of  MAVs  in  three  separate,  but  closely  related, 
mission  areas:  Over-the-Hill-Reconnaissance,  Battle  Damage  Information  (BDI),  and 
Local  Area  Defense.  These  mission  areas  are  examined  and  architectures  created  to 
describe  current  and  future  MAV  capabilities.  From  these  architectures,  areas  of  interest 
relating  to  MAVs  and  their  use  in  the  Air  Force  are  discussed,  focusing  on  enhancing  both 
current  and  future  capabilities  of  those  MAVs  falling  within  the  scope  of  this  thesis. 

1.2  Scope  and  Assumptions 

In  defining  the  scope  and  assumptions  for  this  thesis,  it  became  evident  that  the 
mission  areas  previously  mentioned  define,  to  a  certain  level,  the  application  of  MAVs 
for  this  thesis.  Before  discussing  MAV  applications,  it  is  necessary  to  define  a  UAV  and 
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a  MAV.  As  defined  by  Army  Field  Manual  34-25-2,  Chapter  1  [41],  “UAVs  are  capable 
of  operating  without  an  internal  (human)  pilot;  are  tethered  by  a  radio  control  link;  and 
can  be  preprogrammed  for  both  flight  and  payload  operations  prior  to  launch.”  By  this 
definition,  UAV’s  cover  a  multitude  of  configurations  including  size,  payload,  endurance, 
etc.  This  thesis  concentrates  on  a  tactical  version  of  a  UAV  known  as  the  Mini/Micro 
Aerial  Vehicle  (MAV). 

As  the  name  implies,  MAVs  are  certainly  smaller  in  size  and  in  many  instances,  less 
capable  than  their  larger  counterparts.  However,  their  diminutive  dimensions  afford  faster 
deployment  times,  a  much  smaller  logistic  footprint  in  the  field,  and  eventually,  the  ability 
to  be  carried  by  normal  ground  forces  rather  than  specialized  units.  Further  scoping  the 
problem,  this  thesis  defines  the  MAV  system  to  be  single-man-packable  and  single-man- 
operable.  The  system  also  must  not  require  the  carrier  to  sacrifice  normal  mission  essential 
gear  typically  carried  into  the  field. 

The  products  and  analysis  provided  with  this  research  are  based  on  MAV  systems 
utilized  by  small  units  synonymous  with  special  operations  forces  (SOF).  While  the  scope 
focuses  on  a  single-man-packable/operable  system,  it  is  understood  that  the  specific  user 
determines  how  the  MAVs  are  carried  into  theater.  Another  point  to  remember  is  that  the 
MAV  system  described  in  this  research  is  part  of  a  family  of  intelligence  gathering  systems 
available  to  the  unit.  As  such,  the  MAV  is  primarily  used  for  close-in  (typically  no  more 
than  3km  range)  tactical  reconnaissance  where  using  larger  systems  such  as  the  Pointer 
(RQ-2A),  proves  too  difficult  or  time  consuming  to  employ  for  the  given  situation. 
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II.  Background 

In  order  to  understand  the  focus,  direction,  and  results  of  this  thesis,  a  background 
discussion  of  mini/micro  aerial  vehicles  (MAV)  and  their  operators  is  in  order.  First, 
an  overview  of  the  user  community  is  presented,  followed  by  a  discussion  of  the  selected 
mission  areas.  Presented  next  is  a  brief  overview  of  unmanned  aerial  vehicles  (UAV)  and 
the  sub-category  of  MAVs.  The  final  topic  is  the  background  of  systems  engineering  and 
the  role  it  plays  in  this  effort. 

2.1  The  User:  Special  Operations  Forces 

The  user’s  background,  operating  environment,  mission  tasks,  and  capability  needs 
and  deficiencies  are  all  important  variables  to  understand  when  designing  a  system. 
Ultimately,  the  user  must  be  satisfied  in  order  for  the  design  to  be  successful.  For  this 
thesis,  the  primary  users  are  members  of  the  Air  Force  Special  Operations  Command 
(AFSOC)  which  is  the  Air  Force  component  of  the  United  States  Special  Operations 
Command  (USSOCOM).  The  following  sections  provide  an  overview  of  these  four 
variables  (user  background,  operating  environment,  mission  and  core  tasks,  and  capability 
deficiencies)  which  tie  directly  into  AFSOC’s  roles  and  responsibilities  within  the  special 
operations  community.  Due  to  their  similarities  the  first  two  variables,  user  background 
and  operating  environment,  have  been  combined  into  one  discussion. 

2.1.1  User  Background  and  Operating  Environment.  Special  operations  forces 
(SOF)  conduct  fast,  surgical  operations  at  great  distances  from  established  bases  by 
using  state-of-the-art  communications,  aircraft,  and  specially  trained  personnel  from  each 
branch  of  service.  These  forces  infiltrate  and  exit  areas  that  are  hostile  to  the  United  States, 
or  politically  sensitive  enough  to  warrant  concealment  of  a  US  military  presence.  In- 
depth  knowledge  of  the  region  and  its  inhabitants  can  mean  the  difference  between  success 
and  failure  in  the  realm  of  special  operations.  Typically  special  operations  involve  short 
engagements  using  shock  and  surprise ,  or  long-term  commitments  that  require  patience 
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and  cultural  understanding  [26:6].  Since  their  missions  or  tactics  often  require  covert, 
concealed,  or  discreet  capabilities,  the  systems  they  carry  into  the  field  must  be  robust 
enough  to  survive  the  environment  (i.e.  small,  durable,  quiet,  etc.)  [25:7]. 

Use  of  special  operations  tactics  can  be  traced  back  throughout  human  history. 
They  first  appeared  in  the  United  States  during  the  early  colonial  period,  when  officers 
established  specialized  units  to  fight  against  irregular  enemy  forces.  Until  1986,  the  United 
States  created  and  used  special  operations  forces  on  an  ad  hoc  basis,  frequently  to  the  point 
of  exhaustion  of  the  personnel.  The  units  were  then  disbanded  when  the  crisis  was  over. 
The  scale  and  complexity  of  warfare  has  grown,  thus  increasing  the  time  it  takes  to  build 
a  competent  special  operations  force.  When  the  nation  needed  special  operations  forces 
for  a  sensitive  mission,  the  capability  simply  did  not  exist.  It  took  the  strategic  failure 
of  Operation  Eagle  Claw,  which  was  a  response  to  Iranian  students  taking  50  Americans 
hostage  in  1979,  to  implement  the  concept  of  a  standing  joint  capability  to  conduct  special 
operations.  Although  this  is  a  historical  example  geared  toward  special  operations  forces 
personnel,  the  lesson  learned  also  applies  to  the  equipment  they  use.  Not  only  do  we  need 
to  keep  these  personnel  trained  for  tomorrow’s  war  but  also  develop  and  field  capabilities 
to  ensure  that  the  war  of  tomorrow  is  won  effectively.  One  of  the  goals  of  this  research  is, 
in  fact,  to  consider  future  capabilities  that  MAVs  can  bring  to  the  field  [25:7-8]. 

MAVs  are  not  widely  available,  and  traditionally  special  operations  forces  rely  on 
manned  aircraft,  reconnaissance  teams,  and  satellites  to  provide  the  needed  intelligence 
[26:2].  These  manned  systems  and  space  assets  prove  very  useful  as  information 
providers;  however,  they  are  considered  high  value  assets.  The  term  high  value  asset 
is  used  to  refer  to  those  assets  that  are  in  high  demand  by  units  and  commanders  but 
have  limited  numbers.  One  design  goal  for  MAVs  is  to  provide  low  cost,  highly  capable 
intelligence  gathering  platforms  that  take  the  place  of  such  high  value  systems. 

Why  is  an  architecture  for  the  MAV  needed?  The  answer  lies  in  the  fact  that 
proper  information  management  is  the  key  to  modem  conflicts.  Special  Operations  Forces 
are  often  tasked  directly  by  political  leaders  and  monitored  at  the  national  level  [26: 
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6].  These  operations  cross  all  branches  of  the  armed  service  community  and  require 
detailed  planning  and  rapid  oordination.  All  joint  assets  (air,  ground,  maritime,  space, 
etc.)  must  be  able  to  communicate  quickly  and  efficiently.  Such  efficiency  and  timeliness 
requires  responsive  command  and  control  networks  that  interconnect  the  various  services, 
commands,  and  government  leaders  or  offices.  The  architecture  detailed  in  Chapter  IV 
illustrates  how  the  MAV  system  interacts  with  its  external  environment  to  provide  the 
proper  level  of  communication  and  control  required  by  battlefield  planners. 

Given  the  probability  of  future  attacks,  special  operations  forces  continue  to 
incur  increasing  pressure  to  avoid  failure  meaning  they  must  be  prepared  to  wage  war 
“everywhere,  all  the  time”  [25:7].  To  cope  with  the  complexity  of  these  challenges,  leaders 
of  special  operation  forces  need  greater  capabilities;  most  notably  a  greater  capability 
for  observing  their  surroundings  and  targets  in  real-time  with  immediate  availability.  To 
achieve  this  desired  capability,  the  SOF  teams  require  a  new  surveillance,  reconnaissance, 
and  communication  asset  to  deliver  near-real-time,  full  motion  video  for  tactically 
significant  periods  of  time  [26:1].  This  need  for  near-real-time  video  surveillance  is  the 
driving  requirement  for  this  research  and  further  demonstrates  that  an  MAV  could  be  a 
plausible  solution.  To  further  expand  the  MAV  solution,  other  mission  and  technology 
capabilities  are  explored  which  demonstrate  how  MAVs  can  integrate  with  tomorrows 
joint  special  operations  force. 

2.1.2  SOF  Mission  and  Core  Tasks.  System  design  requires  an  understanding  of 
the  intended  operational  environment,  the  mission  tasks,  background  information  relevant 
to  the  user  and  the  existing  capability  gaps  or  needs.  If  the  system  does  not  address  these 
four  factors,  then  the  system  will  not  fulfill  the  users  needs.  While  the  previous  section 
outlined  the  background  and  general  operating  environment  of  the  special  operations 
forces,  this  section  focuses  on  their  mission  tasks. 

The  United  States  Special  Operations  Command  (USSOCOM)  plans,  directs,  and 
executes  special  operations  in  the  conduct  of  the  War  on  Terrorism  in  order  to  disrupt, 
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defeat,  and  destroy  terrorist  networks  that  threaten  the  United  States,  its  citizens  and 
interest  worldwide.  USSOCOM  organizes,  trains,  and  equips  special  operations  forces 
provided  to  Geographic  Combatant  Commanders,  American  Ambassadors  and  their 
country  teams.  [25:4]  Special  operations  forces  are  responsible  for  nine  principal  missions 
or  core  tasks  with  additional  collateral  tasks.  Collateral  special  operations  activities  apply 
special  operations  capabilities  in  areas  beyond  the  core  tasks  [26].  These  areas  include 
security  assistance,  humanitarian  assistance,  peace  operations,  coalition  support,  counter¬ 
drug  operations,  personnel  recovery,  and  special  activities.  The  nine  core  tasks  identified 
by  USSOCOM  [25]  are  as  follows: 

1.  Unconventional  Warfare  (UW) 

2.  Direct  Action  (DA) 

3.  Special  Reconnaissance  (SR) 

4.  Foreign  Internal  Defense  (FID) 

5.  Counter-Terrorism  (CT) 

6.  Psychological  Operations  (PSYOP) 

7.  Civil  Affairs  Operations  (CAO) 

8.  Information  Operations  (10) 

9.  Counter-Proliferation  (CP)  of  weapons  of  mass  destruction  (WMD) 

All  of  these  tasks  are  equally  important  to  the  SOF  mission;  however,  this  research 
focuses  only  on  the  core  tasks  of  special  reconnaissance  and  counter-terrorism.  This 
allows  the  current  mission  tasks  to  align  with  current  (or  AS-IS)  MAV  capabilities.  Taking 
MAV  capabilities  and  demonstrating  how  they  aid  special  operations  forces  is  shown  in 
Chapter  IV. 

The  special  reconnaissance  task  (also  referred  to  as  recon)  includes  reconnaissance 
and  surveillance  actions  that  collect  or  verify  significant  information  complementing  or 
supplementing  national  or  theater  intelligence  assets  [25].  These  special  reconnaissance 
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teams  are  often  the  eyes  and  ears  of  unconventional  warfare,  direct  action,  counter¬ 
terrorism,  and  foreign  internal  defense  operations  [26].  The  ability  to  broadcast  imagery 
over  long  distances  is  required  in  order  to  increase  each  team’s  overall  situational 
awareness.  Another  need  to  increase  mission  effectiveness  is  the  need  for  low  probability- 
of-intercept  communication,  which  in  turn  complements  the  need  for  long  range 
communications.  Based  on  current  technologies  as  the  communication  range  increases 
the  probability-of-intercept  also  increases.  This  applies  to  the  MAVs  design  trade-offs  in 
a  sense  that  the  user  and  system  designer  will  have  to  choose  either  long-range  or  low 
probability-of-intercept. 

The  core  task  of  counter-terrorism  requires  highly  trained  personnel  that  can 
preempt  or  resolve  terrorist  incidents  outside  the  United  States.  This  is  one  of  the 
high-profile  tasks  of  today’s  special  operations  forces  [25].  The  counter-terrorism  task 
is  extremely  dependent  on  intelligence  intensive  because  it  involves  such  activities  as 
finding,  isolating,  and  neutralizing  or  capturing  terrorists.  If  the  intelligence  can  be  made 
available  in  a  timely  manner,  then  teams  of  special  operations  forces  will  be  able  to 
increase  the  success  of  missions  such  as  rescuing  hostages,  attacking  the  terrorist  infras¬ 
tructure,  and  recovering  sensitive  material  from  a  terrorist  organization  [26]. 

While  not  listed  as  a  core  task,  re- supplying  special  operations  forces  in  the  field 
is  implied  with  certain  tasks,  such  as  special  reconnaissance.  This  is  often  a  challenging 
process  because  special  operations  forces  tend  to  work  great  distances  from  base  camps, 
typically  behind  or  in  close  relation  to  enemy  lines  and  far  from  major  supply  points 
[26].  In  most  cases,  the  teams  must  traverse  difficult  terrain  or  parachute  into  isolated 
areas  where  ground  transportation  is  not  feasible  or  tactically  advantageous.  Throughout 
this  research,  the  requirement  for  resupplying  the  forces  in  the  field  is  assumed  and  the 
architectural  products  presented  in  Chapter  IV  do  not  reflect  the  logistic  support  aspects 
required  for  the  MAY  system. 
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2.1.3  SOF  Capability  Deficiencies.  The  previous  sections  discussed  three  of 
the  four  design  factors  for  system  design:  user  background,  operating  environment  and 
mission  tasks.  This  section  expounds  on  the  fourth  factor  capability  needs.  To  meet 
the  numerous  tasks  facing  special  operations  forces  and  to  ensure  that  they  have  the 
appropriate  equipment  and  resources,  Congress  authorized  USSOCOM  its  own  head-of- 
agency  authority,  program  authority  and  budget  for  research,  development,  and  acquisition 
of  special  operations  unique  material  and  equipment  [26].  Using  a  modernization  process, 
the  USSOCOM  begins  with  a  strategy  review  to  determine  where  the  capabilities  and 
attributes  can  be  incorporated  into  various  joint  strategy  documents.  The  process  follows 
an  approach  of  strategy-to-task,  task-to-need,  need-to-concept,  concept-to-technology, 
and  technology-to-execution  [26].  This  modernization  process  results  in  the  identification 
of  several  capability  deficiencies  which  are  broken  into  three  domains:  command-control- 
communications  (C3),  intelligence,  and  resupply.  This  provides  designers  with  a  broad 
idea  of  user  requirements.  Table  2.1  lists  the  capability  deficiencies,  extracted  from 
Maj  Stephen  Howard’s  Special  Operations  Forces  and  Unmanned  Aerial  Vehicles  [26], 
that  were  relevant  to  this  study  and  MAVs. 


Table  2.1  SOF  Capability  Deficiencies  listed  by  domain 


Domain 

Capability  Deficiencies 

Command,  Control, 
and  Communications 

Potential  for  enemy  to  monitor  or  destroy  our 
information  systems. 

Intelligence 

-  No  real/near-time  imagery  from  national  systems 

-  No  real-time  interface  between  aircraft,  planners, 
and  intel  systems 

-  No-real-time  imagery  for  target  study 

-  No  all-source  threat  location  data 

-  Enhanced  target  identification  and  marking 
capability  required 

Resupply 

Need  resupply  of  expendables  (batteries,  food,  water, 
medical,  ammo) 
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2.2  Mission  Areas 


The  three  intelligence,  surveillance  and  reconnaissance  (ISR)  missions  for  this 
thesis  are  Over-the-hill  Reconnaissance,  Battle  Damage  Information,  and  Local  Area 
Defense.  A  mission  area  is  simply  a  more  defined  or  scoped  task  that  relates  to  one  or 
more  of  the  core  tasks,  thus  making  mission  areas  a  subset  of  core  tasks.  Recall  that 
this  thesis  focuses  on  the  special  reconnaissance  and  combating  terrorism  core  tasks.  The 
following  discussion  scopes  these  mission  areas  as  they  relate  to  the  core  tasks. 

Over-the-hill  reconnaissance  enhances  a  SOF  teams  situational  awareness  by 
extending  their  beyond  line-of-sight  ISR  capabilities.  This  mission  area  got  its  name  from 
the  idea  that  a  user  could  deploy  a  miniature  unmanned  system  to  peer  over  a  hill  or  to  get 
a  birds  eye  view  of  complex  terrain  in  order  to  assess  suspected  enemy  positions.  There 
are  many  systems  that  possess  this  capability;  however,  many  are  high  value  assets  and 
others  are  simply  not  available  due  to  mission  sensitivity  or  execution  area.  What  SOF 
teams  require  is  the  capability  to  observe  the  enemy  and  their  surroundings  regardless  of 
obstacles. 

Battle  Damage  Information  collects  information  on  the  damage  inflicted  upon  the 
enemy  following  an  offensive  strike.  Battle  Damage  Information  (BDI)  is  similar  to  Battle 
Damage  Assessment  (BDA),  but  lacks  the  ability  and/or  authority  to  properly  assess 
and  make  a  decision  based  on  intelligence  gathered.  BDA,  on  the  other  hand,  implies 
that  the  information  has  or  is  being  transformed  into  actionable  intelligence  for  further 
use  by  forces.  In  order  to  gather  the  needed  intelligence,  commanders  need  access  to 
reconnaissance  platforms.  If  access  is  not  possible,  it  may  take  a  significant  amount  of 
time  in  order  to  get  the  information  needed  for  the  assessment.  Special  operations  forces, 
or  other  units  already  in  the  field,  have  the  potential  to  provide  time  sensitive  intelligence 
information  if  equipped  with  MAV  systems.  The  MAV  can  deploy  from  a  nearby  unit  to 
gather  the  intelligence  needed  and  route  this  information  to  personnel  qualified  to  conduct 
the  assessment. 


2-7 


Local  Area  Defense  (LAD)  covers  any  scenario  in  which  SOF  or  other  friendly 
forces  are  defending  against  an  enemy  attack  or  preventing  insurgents  from  entering  an 
area.  This  mission  area  requires  rapid  response  from  the  defenders  if  they  wish  to  succeed. 
In  this  case,  the  MAV  can  easily  serve  as  a  rapidly  deployable  sensor  platform  to  gather 
the  needed  information. 

Though  these  mission  areas  are  different  in  execution,  they  are  very  similar  when 
considering  the  required  information  exchanges  and  materiel  requirements.  As  such,  the 
remainder  of  this  thesis  centers  on  a  consolidated  view  of  the  mission  areas;  expounding 
on  the  individual  mission  areas  only  when  required. 

2.3  Unmanned  Aerial  Vehicle 

The  previous  two  sections  focused  on  the  special  operations  forces  background  and 
the  intended  mission  areas  for  MAVs.  It  was  also  mentioned  that  MAVs  are  a  subset  of  the 
larger  category  of  Unmanned  Aerial  Vehicles  (UAVs).  This  section  provides  a  background 
of  UAV  classification  and  history  of  their  development  and  usage  in  the  modem  military. 

By  definition,  any  aircraft  not  carrying  a  pilot  can  be  considered  a  UAV.  Due  to 
this  broad  definition,  several  classifications  exist  to  further  delineate  UAVs  of  different 
design  and  capability.  The  first  of  these  is  a  remotely  piloted  vehicle  (RPV).  RPVs  are 
those  unmanned  platforms  requiring  full  control  by  a  ground  station  or  separate  manned 
aircraft.  These  systems  are  exemplified  by  off-the-self  remote  control  aircraft  found  in 
hobby  shops.  The  second  category,  known  as  drones,  are  a  self-controlling  platform  that 
are  preprogrammed  prior  to  launch  and  cannot  accept  mission  changes  once  dispatched 
[20].  The  last  category  of  UAVs  is  capable  of  self-navigation,  in-flight  reprogramming 
and  can  perform  autonomous  take-off  and  landing  if  equipped  to  do  so.  Though  they  do 
not  have  a  special  descriptor  to  separate  them  from  RPVs  and  drones,  the  remainder  of 
this  thesis  assumes  the  term  UAV  abides  by  the  latter  definition. 

The  use  of  UAVs  dates  back  to  1887  when  Englishman  Douglas  Archibald 
attempted  to  tackle  the  problem  of  over-the-hill  observation  by  attaching  a  camera  to  a 
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kite  and  then  flying  the  platform  high  enough  to  observe  the  enemy  [44].  Other  examples 
of  early  UAVs  include  the  use  of  explosive  laden  balloons  during  the  Civil  War,  by  both 
Union  and  Confederate  soldiers  and  during  World  War  Two  by  the  Japanese.  The  United 
States,  also  during  WWII,  attempted  to  use  operational  aircraft  in  an  unmanned  fashion  by 
flying  the  aircraft  to  a  specified  altitude  and  then  bailing  out,  allowing  the  explosive-laden 
aircraft  to  continue  to  their  targets  [19]. 


The  war  in  Vietnam  saw  the  productive  use  of  drones  in  the  area  of  intelligence. 
Ryan  BQM-34  Firebee  (Figure  2.1)  UAVs  were  used  over  North  Vietnam  for  day  and 
night  missions  using  payloads  primarily  composed  of  conventional  cameras  or  signals 


Figure  2.1  BQM-34A  FIREBEE 


intelligence  equipment  [19].  Ultimately,  Firebees  flew  more  than  3,400  sorties 
in  support  of  American  objectives.  The  QH-50  DASH  (Figure  2.2)  remotely  piloted 
helicopter  (RPH)  was  also  used  by  Marines  for  beach  reconnaissance  and  spotting  in 
Vietnam  [43]  but  the  technology  required  for  this  system  was  not  mature  enough  for  the 
program  to  continue. 

Although  these  examples  have  proven  the  potential  for  UAVs  to  perform 
reconnaissance  and,  in  some  cases,  strike  missions,  many  countries  avoided  UAV 
development  due  to  extensive  costs  and  bulky  sensor  packaging  [20].  In  fact,  it  was 
more  common  to  find  a  UAV  serving  as  a  decoy  providing  anti-aircraft  practice  for  navel 
gunner’s  or  guiding  munitions  to  their  targets,  such  as  the  German  V-Series  rockets  during 
WWII,  than  it  was  to  find  them  performing  reconnaissance  missions  [16].  After  the  mid- 
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Figure  2.2  Gyrodyne  QH-50C  DASH  [36] 


1960’s,  the  size  and  cost  of  the  electronics  began  to  rapidly  decrease;  however,  this  did  not 
create  a  significant  change  in  interest  levels  for  UAVs. 

General  interest  in  UAVs  had  a  noteworthy  increase  after  the  Israeli  military  used 
them  against  the  Syrian  air  defense  system  in  the  Bekaa  Valley  in  1982  for  reconnaissance, 
jamming,  and  as  decoys  [16].  Despite  the  numerous  problems  encountered  by  UAV 
systems,  the  Israelis  proved  that  UAVs  could  perform  valuable  combat  service  in  an 
operational  environment.  Countries  around  the  world  began  to  ramp  up  their  UAV 
programs  by  designing  systems  to  perform  dangerous  and  dull  missions  typically  handled 
by  manned  aircraft  [20]. 

During  Operation  Desert  Storm,  the  Navy  and  Marines  operated  RQ-2A  Pioneer 
(Figure  2.3)  UAV  systems  to  provide  target  identification  enabling  the  engagement  of 
Iraqi  defense  forces  on  Faylaka  island  [19]. 

More  recently,  UAVs  have  been  employed  to  combat  terrorism  in  both  Afghanistan 
and  Iraq.  Predator  UAVs  have  been  on  the  cutting  edge  of  experimentation  as  this 
platform,  primarily  designed  for  intelligence  gathering,  has  also  been  modified  to  provide 
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Figure  2.3  RQ-2A  Pioneer  UAV  [36] 


an  offensive  capability.  While  UAVs  experience  more  interest  and  funding,  they  are 
typically  built  to  fill  a  specific  military  need  and  are  classified  based  on  their  capabilities. 

UAV  classifications  vary  depending  on  military  service  branches,  authors,  and 
manufactures.  Some  of  the  more  common  classifications  are:  tactical  and  endurance; 
lethal  and  non-lethal;  very  low  cost  close  range,  close  range,  short  range,  and  medium 
range;  expendable  and  recoverable.  The  users’  needs  and  operating  conditions  typically 
drive  which  type  of  UAV  is  best.  In  the  case  of  over-the-hill  reconnaissance,  UAVs  are 
classified  as  tactical  (short  range,  field  supported),  non-lethal,  very  low  cost  close  range, 
and  expendable  (with  the  option  to  recover). 

2.4  Mini  and  Micro  Aerial  Vehicles 

While  both  mini  and  micro-UAVs  (MAVs)  are  a  subset  of  UAVs,  MAVs  are  unique 
due  to  their  smaller  size.  This  section  introduces  some  of  the  unique  characteristics  MAVs 
possess  and  provides  a  systems  perspective  for  a  typical  MAV  system.  From  this  section 
onward,  the  term  MAV  refers  to  both  mini  and  micro-UAVs. 

2.4.1  Characteristics.  An  MAVs  small  size  brings  about  many  unique 
operational,  logistic,  and  acquisition  characteristics.  Operationally,  MAVs  can  provide 
capabilities  to  smaller  units  that  heretofore  were  unachievable  because  UAV  systems  were 
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simply  too  expensive  and  complex  to  be  utilized  by  small  military  units.  Additionally, 
these  systems  were  unable  to  provide  time-critical  information  for  the  units  that  would 
most  benefit  from  their  use  in  the  field.  MAVs  can  also  have  a  variety  of  payloads  that 
can  be  manufactured  for  a  single  airframe  which  enables  the  concept  of  reusability  by 
interchanging  payloads  in  the  field.  Logistically  speaking,  MAVs  can  be  designed  to  have 
a  relatively  small  footprint.  As  for  the  acquisition  side  of  the  house,  MAVs  present  a  faster, 
better,  cheaper  approach  to  their  development,  procurement,  and  fielding  [27].  These 
characteristics  are  very  beneficial,  but  with  every  benefit  there  are  challenges. 

The  main  challenges  with  MAVs  are  their  limited  payload  weight,  aerodynamics, 
systems  integration,  and  mission  utility.  The  point  here  is  to  recognize,  as  with  every 
system,  that  there  are  design  challenges  that  need  to  be  considered.  To  place  some  signif¬ 
icance  and  to  give  the  reader  a  better  idea  of  the  term  small  size ,  the  following  table 
better  characterizes  a  MAVs  operational  scale.  The  characteristics  shown  in  Table  2.2  are 
averages.  A  particular  mini-UAV  or  micro-UAV  may  have  values  smaller  or  larger  than 
the  ones  presented  in  the  table. 


Table  2.2  Sample  Characteristics  of  Mini  and  Micro-UAVs  [18:210] 


Characteristic 

Mini-UAV 

Micro-UAV 

Weight  (g) 

4540 

49 

Wingspan  (cm) 

121 

15 

Aspect  Ratio 

7 

3 

Wing  Area  (cm2) 

2096 

76 

CL  (Aerodynamic  Lift  Coefficient) 

0.6 

0.6 

CL/CD  (Aerodynamic  Lift/Drag  Coefficient) 

26 

5 

Propeller  Efficiency 

0.8 

0.5 

Electrical  Efficiency 

0.6 

0.6 

Average  Power  (W) 

178 

5.1 

Average  Power/Wing  Area  (W/cm2) 

0.085 

0.068 

A  general  picture  of  how  MAVs  stack  up  to  other  aircraft  based  on  size  is  provided 
in  Figure  2.4.  This  figure  provides  a  point  of  reference  for  mini  and  micro-UAVs,  and 
attempts  to  further  define  mini-UAVs  as  fitting  somewhere  in  between  micro-UAVs  and 
small  wingspan  UAVs. 
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Figure  2.4  The  MAV  compared  to  existing  flight  vehicles  extracted  from  [32:3] 

2.4.2  Systems  Perspective.  A  typical  MAV  system  is  composed  of  an  air  vehicle, 
ground  control  or  base  station,  payload,  and  data  link  [16].  Many  UAV  systems  also 
include  support  subsystems  designed  to  aid  in  launch  and  recovery,  ground  handling,  and 
system  maintenance.  Due  to  the  MAVs  size  and  weight,  these  support  subsystems  will  not 
be  as  complex  and,  in  some  cases,  not  required  at  all.  The  launching  and  recovery  of  a 
MAV  does  not  require  a  system  but  an  operator  initiated  event  (on/off  switch,  hand  launch, 
etc.).  Although  these  subsystems  or  events  are  important  to  a  MAVs  operation,  only  the 
air  vehicle,  ground  control  or  base  station,  payload  and  data  link  systems  are  discussed 
further. 

The  air  vehicle, as  shown  in  Figure  2.5  is  the  airborne  piece  of  the  system  that 
includes  the  airframe,  propulsion  unit,  flight  controls,  power  source,  and  communications 
equipment.  The  electric  motor  serves  as  the  propulsion  unit  in  most  MAVs  but  combustion 
engines  are  also  a  viable  alternative.  Power  sources  are  typically  either  batteries  or 
combustible  fuel.  Current  MAV  navigation  encompasses  a  broad  range  of  systems  to 
include  an  on-board  autopilot,  inertial  navigation  system  (INS),  global  positioning  systems 
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(GPS),  and  memory  to  store  mission  related  data  (waypoints).  Onboard  communications 
equipment  in  most  MAVs  usually  consists  of  an  antenna,  transmitter,  receiver,  and  the 
supporting  hardware  and  software. 


Figure  2.5  Example  of  a  MAY 


The  ground  control  or  base  station  plays  an  important  role  in  today’s  reconnaissance 
based  MAVs  because  they  represent  the  operational  control  center  for  the  MAV  system. 
The  ground  station  typically  manages  video,  command  and  control  functions,  and  the 
processing  of  telemetry  data  received  from  the  air  vehicle  [16].  Key  systems  that  need 
to  be  present  include  control  and  display  consoles,  video  and  telemetry  instrumentation, 
signal  processing,  data  terminals,  and  communications  equipment  including  antennas. 

In  most  cases,  the  MAV  payload  is  the  most  expensive  piece  of  the  system.  For 
reconnaissance  missions,  the  payload  usually  includes  video  cameras  capable  of  either  day 
or  night  (infrared)  operations.  Other  possible  payloads  include:  target  designation  using  a 
laser,  radar  sensors  such  as  a  moving  target  indicator  or  synthetic  aperture  radar,  electronic 
warfare  (EW)  systems,  meteorological  sensors,  and  chemical  sensing  devices  [16].  Due 
to  size,  power,  and  weight  restrictions  most  of  the  signal  processing  is  left  to  the  base 
station;  however,  some  limited  processing  may  still  occur  on  the  air  vehicle  depending  on 
the  payload.  As  technology  continues  toward  smaller  components  and  faster  processing, 
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MAV  capabilities  will  continue  to  grow  providing  operators  critical  tools  necessary  for 
mission  accomplishment. 

One  of  the  key  subsystems  for  any  MAV  is  the  data  link.  This  link  provides 
bi-directional  communication  either  on  demand  or  on  a  continuous  basis.  An  up-link 
provides  vital  command  instructions  to  the  air  vehicle.  The  down-link  contains  two  types 
of  information;  one  for  command  acknowledgment  and  status  information,  and  the  other 
for  sensor  data  such  as  radar  or  video  feedback  [16].  Figure  2.6  helps  to  illustrate  MAV 
systems  by  providing  an  example  of  a  typical  system  broken  into  key  subsystems  and  then 
showing  how  these  subsystems  are  tied  together.  As  new  technologies  and  capabilities 


Air  Vehicle 


Base  Station 


Figure  2.6  A  Typical  MAV  System 


are  explored,  new  systems  and/or  subsystems  are  needed,  particularly  in  the  area  of  the 
various  payloads. 

From  this  level,  systems  integration  is  straightforward;  however,  the  actual  physical 
integration  of  hardware  and  software  presents  one  of  the  greatest  challenges  in  MAV 
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design.  As  vehicle  size  decreases  or  functionality  increases,  the  integration  becomes 
more  complex  [32:7].  Similar  to  Figure  2.6,  Figure  2.7  focuses  more  on  the  general 
physical  hardware  integration  of  a  MAV.  This  MAV  system  concept  helps  guide  the  system 
architecture  products  and  future  capabilities  presented  later  on. 
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Figure  2.7  MAV  Hardware  Integration  [32:7] 


2.5  Systems  Engineering  and  Architectures 

Designing  a  system  such  as  a  MAV  to  meet  the  current  and  future  requirements  of  its 
users  in  a  system  of  systems  (SoS)  and  family  of  systems  (FoS)  environment  is  a  complex 
problem.  Missions  and  operating  environments  may  change  and  systems  that  interface 
with  the  MAV  may  change.  The  ability  to  continue  to  utilize  an  existing  MAV  system 
in  constantly  changing  and  unique  environments  while  providing  a  desired  capability  is 
a  problem  that  sits  above  the  component  design  level.  That  is  why  the  use  of  a  systems 
approach  to  this  problem  is  needed.  The  use  of  architectural  views  to  describe  a  MAV 
system  should  facilitate  its  development. 

2.5.1  Systems  Engineering  Overview.  Systems  engineering,  as  a  discipline,  is 
defined  in  many  ways.  The  International  Council  on  Systems  Engineering  (INCOSE) 
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defines  it  as  “an  interdisciplinary  approach  and  means  to  enable  the  realization  of 
successful  systems.  It  focuses  on  defining  customer  needs  and  required  functionality 
early  in  the  development  cycle,  documenting  requirements,  then  proceeding  with  design 
synthesis  and  system  validation  while  considering  the  complete  problem”  [7].  More 
simply  put,  “Systems  Engineering  is  the  design,  production,  and  maintenance  of 
trustworthy  systems  within  cost  and  time  constraints”  [37]. 

It  can  be  argued  that  systems  engineering,  in  some  form,  has  been  around  since 
many  of  the  ancient  wonders  of  the  world  were  built.  It  is  difficult  to  imagine  immense 
structures  such  as  the  Pyramid  of  Khufu  in  Egypt,  the  Temple  of  Artemis  at  Ephesus,  or  the 
Hanging  Gardens  of  Babylon  were  designed  and  constructed  without  “an  interdisciplinary 
approach  and  means  to  enable  the  realization  of  these  successful  systems”  [7]. 

The  presence  of  a  systems  engineering  focus  was  also  evident  at  other  times 
throughout  history  whenever  a  large  and/or  complex  system  was  designed  and  constructed. 
Examples  include  the  Roman  aqueducts,  the  Great  Wall  of  China,  European  castles  and 
cathedrals,  and  centuries  of  ship  building.  As  one  will  notice,  prior  to  the  industrial 
and  technological  revolutions,  most  large  and  complex  system  design  efforts  were  civil 
engineering  or  classically  architectural  structures.  Architects  were,  in  a  way,  the  first 
systems  engineers.  “Indeed,  the  Greek  word  architecton  means  master  builder  or  master 
mason.  The  term  describes  one  who  designs  and  builds  structures  whose  form  and  function 
is  both  appealing  and  useful.  ...The  architect  has  the  special  role  of  eliciting  and  converting 
the  needs  and  desires  of  the  customer  that  commissions  him  into  a  design  that  will  be 
especially  satisfying  to  that  customer”  [31:227].  This  is  why  the  discipline  of  systems 
engineering  so  closely  relates  its  processes  and  tools  to  those  of  an  architect. 

The  Industrial  Revolution  brought  about  a  major  thrust  to  design  and  enable 
machines  to  perform  tasks  that  previously  only  humans  performed.  The  design  of  these 
machines  and  tools  was  initially  understandable  and  straightforward.  Many  of  the  systems 
were  relatively  small  and  the  tool-users  themselves  were  likely  a  part  of  the  design  process. 
There  also  existed,  in  many  cases,  a  trial  and  error  approach  to  the  system  design  in 
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absence  of  more  formally  defined  systems  engineering  processes  [37:6].  As  the  machines 
and  tools  became  more  and  more  complex,  single  tool-users  could  no  longer  design  the 
system.  Teams  of  designers  and  technically  specialized  individuals  were  now  necessary. 
With  a  new  host  of  subsystem  and  component  specialists  working  on  complex  systems, 
there  developed  a  need  to  integrate  and  organize  the  design  process  in  a  more  efficient 
manner. 

Following  the  end  of  World  War  II,  the  boom  of  the  technological  age  began  to  take 
off  both  figuratively  and  literally.  The  push  of  opposing  nationalities  to  develop  longer- 
range  missiles,  better  aircraft,  and  nuclear  capabilities  placed  large  amounts  of  competitive 
pressure  on  fast  and  effective  design  processes.  The  countries  and  development  teams 
with  more  efficient  and  productive  design  processes  gained  national  and  military  leverage 
[29:6].  This  pressure  to  design  and  deploy  systems  to  meet  the  users  need  continued 
throughout  the  past  few  decades,  both  in  the  military  and  commercial  sectors.  The 
role  of  the  systems  engineer  could  be  viewed  as  the  integrator  between  all  of  the  other 
disciplines  necessary  to  design  the  system.  Standardized  languages  and  system  represen¬ 
tation  techniques  were  developed  and  used  to  enable  all  of  the  key  players  of  a  system  to 
see  their  own  role  in  the  complete  system. 

The  advent  of  the  information  age,  through  the  use  of  computers  and  software, 
presented  a  new  host  of  challenges  for  the  systems  engineering  discipline.  In  the  largely 
abstract  environment  of  software  development,  there  now  exists  the  need  to  have  effective 
and  efficient  processes  in  place  that  integrate  all  aspects  of  the  software  development. 
Developers  of  different  parts  of  an  overall  software  package  need  some  way  of  conceptu¬ 
alizing  the  end  result.  That  end  result,  and  the  satisfaction  of  the  users’  requirements,  were 
more  important  than  the  sum  of  all  the  individual  system  pieces.  New  and  tailored  ways  of 
viewing  and  communicating  the  system  to  other  key  players  and  being  able  to  aggregate 
the  subsystems  into  a  whole,  were  now  the  focus  of  systems  engineers.  This  focus,  and 
the  systems  themselves,  are  many  times  too  complex  to  visualize  in  simple  terms.  The 
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systems  engineer  must  use  tools  in  the  form  of  a  systems  architecture  to  aid  the  design  and 
integration  process. 


2.5.2  Architectures  Overview.  One  of  the  more  straight-forward,  and  widely 
accepted,  depictions  of  the  systems  engineering  process  can  be  seen  in  Figure  2.8.  The 
design  of  a  system  starts  with  the  analysis  of  user  requirements,  followed  by  the  functional 
analysis  and  allocation  of  the  system,  and  then  the  actual  design  synthesis  of  the  physical 
system.  The  process  is  iterative,  such  that  each  step  in  the  process  may  to  a  preceding  step 
to  ensure  that  the  design  is  meeting  the  earlier  step’s  needs  and  requirements.  That  is  why 
there  are  the  requirements,  design,  and  verification  loops. 


INPUTS 


OUTPUTS 


Figure  2.8  Systems  Engineering  Process 


It  should  also  be  noted  that  there  is  an  analysis  and  control  step  in  the  process.  From 
any  of  the  other  stages  in  the  process,  the  design  of  the  system  should  be  regulated  by  a 
defined  process  and  aided  through  the  use  of  tools  to  ensure  a  traceable  and  controlled 
design.  Systems  engineering  uses  architectures  as  a  set  of  tools  for  this  step  in  teh  SE 
process. 
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The  term  architecture  is  defined  by  IEEE  Std  1471-2000  as  “the  fundamental  organi¬ 
zation  of  a  system  embodied  in  its  components,  their  relationships  to  each  other,  and  to 
the  environment,  and  the  principles  guiding  its  design  and  evolution”  [28:3]. 

Three  fundamental  views  create  an  architecture  description:  the  operational  view 
(OV),  systems  view  (SV),  and  technical  standards  view  (TV).  Although  the  fourth  view, 
the  all-view  (AV),  provides  information  pertinent  to  the  entire  architecture,  it  does  not 
represent  any  of  the  aforementioned  architectural  views.  As  seen  in  Figure  2.9,  each  view 
plays  a  special  role  in  describing  the  system.  The  operational  view  identifies  what  needs 
to  be  accomplished  and  who  does  it.  The  systems  view  relates  systems  and  characteristics 
to  operational  needs.  The  technical  standards  view  prescribes  standards  and  conventions 
used  to  develop  the  system.  As  can  also  be  seen  in  Figure  2.9,  each  view  provides  elements 
to  the  other  views  that  allow  the  resulting  architecture  to  be  integrated  [24:2-1].  These 
views  and  their  components  are  covered  in  more  detail  in  Chapter  III. 
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Figure  2.9  DoDAF  Views  and  their  Integration  [24:2-1] 


While  architectures  are  of  evident  value  to  the  systems  engineer,  they  also  play 
a  vital  role  in  communicating  with  the  key  operators/users  of  a  system.  Without  many 
of  the  architecture  products,  key  users  may  have  difficulty  understanding  aspects  of  the 
integrated  system.  The  architecture  provides  the  necessary  documentation  of  the  systems 
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operating  environment,  requirements,  functions,  subsystems,  inputs,  outputs,  etc.  The 
documentation  also  provides  the  traceability  necessary  to  enable  the  realization  of  the 
entire  system. 

2.5.3  SE  and  Architecture  Policy.  Beyond  the  practical  benefits  of  architectures, 
they  are  also  now  required  by  law  and  high-level  policy  for  acquisition  programs  within 
US  government  agencies.  The  Clinger-Cohen  Act  of  1996  requires  all  executive-level 
departments  to  use  architectures  to  develop,  maintain  and  facilitate  integrated  IT.  In  the 
DoD,  it  also  requires  architectures  for  National  Security  Systems  (NSS).  A  NSS  is  any 
telecommunication  or  information  system  operated  by  the  US  Government,  in  which 
the  function,  operation,  or  use  involves  intelligence  activities.  The  activities  can  be 
cryptologic  activities  related  to  National  Security  or  the  command  and  control  of  military 
forces.  Activities  may  also  require  the  use  of  equipment  that  is  an  integral  part  of  a 
weapon  or  weapons  system,  or  be  critical  to  direct  fulfillment  of  military  or  intelligence 
missions  [1],  This  description  of  a  NSS  relates  directly  to  the  role  and  missions  of  MAYs. 
The  mission  areas  for  MAVs  this  research  develops  deal  directly  with  imformation  systems 
that  involve  intelligence  activities.  The  information  that  they  collect  can  also  influence  the 
command  and  control  of  military  forces  and  be  an  integral  part  of  the  employment  of 
weapon  systems.  Therefore  the  Clinger-Cohen  Act  requires  an  architecture  for  MAVs. 

In  response  to  this  act,  executive-level  departments  and  agencies  also  updated 
and  changed  many  high-level  policies  to  include  Office  of  Management  and  Budget 
(OMB)  Circulars  A- 130  and  A-ll.  These  circulars  directed  that  all  federal  organizations 
have  formal  frameworks  for  developing  architectures  and  demonstrate  how  their  capital 
planning  and  budgeting  link  to,  and  support,  those  architectures  [2]  [35]. 

Within  the  DoD,  the  Chairman  of  the  Joint  Chiefs  of  Staff  provided  instruction 
through  CJCSI  3170.01,  “Joint  Capabilities  Integration  and  Development  System 
(JCIDS)”  to  require  integrated  architectures  as  a  formal  part  of  the  DoD  acquisition  system 
[3].  The  Initial  Capabilities  Document  (ICD),  Capability  Development  Document  (CDD), 
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and  Capability  Production  Document  (CPD)  each  support  key  descision  milestones  in  the 
process.  They  also  all  require  specific  architecture  products  to  support  those  milestones. 
Figure  2. 10  shows  how  these  documents  and  milestones  are  a  part  of  the  DoD’s  acquisition 
process. 
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Figure  2.10  DoD  Aquisition  Process  [13:3] 

With  these  major  organizational  and  policy  changes  in  the  last  decade,  architectures 
are  now  important  not  only  for  the  successful  development  of  the  actual  system,  but  also 
for  the  effective  operation  of  the  organizations  that  develop  the  system.  For  these  reasons, 
an  integrated  architecture  is  necessary  to  document,  develop  and  lay  the  ground  work  for 
a  successful  MAV  system.  Currently  there  are  no  architectures  for  MAV  systems,  their 
current  mission  areas  or  future  mission  areas.  In  order  to  efficiently  implement  MAVs  in 
the  DoD,  a  baseline  architecture  representing  current  MAV  capabilities  is  imperative  and 
is  the  impetus  for  this  thesis. 
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III.  Methodology 

The  area  of  systems  engineering,  its  principles  and  tools  have  been  selected  to  examine  the 
intelligence,  surveillance  and  reconnaissance  (ISR)  mini/micro  aerial  vehicle  (MAV).  This 
approach  is  ideal  given  the  variety  of  systems  that  must  interact  to  make  the  MAV  useful 
in  its  missions.  Systems  engineering  relies  heavily  on  its  architectural  products  to  promote 
overall  system  understanding.  This  chapter  discusses  the  importance  of  traceability 
in  the  Systems  Engineering  (SE)  process,  gives  an  overview  of  DoD  development  of 
architectures  and  then  closes  with  an  in-depth  description  of  all  pertinent  architectural 
products.  Since  the  products  are  numerous  and  form  many  perspectives,  traceability 
is  vital  to  keep  the  architecture  understandable  and  tied  back  to  the  original  system 
requirements. 

3.1  Providing  Traceability 

Throughout  any  effort  to  produce  an  integrated  architecture,  traceability  is  key. 
Traceability  progresses  from  the  identification  of  a  capability  gap  to  the  assignment  of 
system  components  to  perform  specific  functional  tasks. 

“Traceability  requires  the  establishment  of  an  unbroken  chain  of  comparisons  to 
stated  references”  [33].  This  reference  describes  traceability  in  the  way  that  a  crime 
scene  investigator  handles  evidence  in  a  criminal  case.  There  must  be  that  unbroken  chain 
such  that  a  case,  or  in  this  thesis  a  conclusion,  can  be  well-founded  and  understandable. 
“Requirements  traceability  is  the  ability  to  describe  and  follow  the  life  of  a  requirement, 
in  both  a  forward  and  backward  direction,  i.e.  from  its  origins,  through  its  development 
and  specification,  to  its  subsequent  deployment  and  use,  and  through  periods  of  ongoing 
refinement  and  iteration  in  any  of  these  phases”  [22:94-101].  Not  only  does  traceability 
tie  a  system  design  back  to  its  requirements,  but  it  also  allows  the  designers  to  step 
forward  and  backward  through  the  design  while  still  understanding  all  of  the  defined  and 
standardized  pieces. 
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Traceability  is  a  characteristic  of  an  architecture  that  allows  the  reader/user  to 
understand  the  progression  of  a  thought  throughout  the  entire  architectural  design  process. 
It  is  the  description  of  understandable  links  between  various  views  and  can  be  used 
to  assess  how  the  original  capability  needs  are  being  met  by  the  designed  architecture. 
Without  traceability,  potential  exists  to  ignore  original  capability  gaps  and  once  the 
architecture  is  designed,  it  may  be  only  a  set  of  detailed  views;  not  an  integrated 
architecture. 

The  traceability  of  a  capability  gap  begins  the  system  design  process  providing 
the  links,  during  concept  exploration  and  eventually  the  chosen  system  design.  Once  a 
concept  has  been  selected,  the  high  level  measures  obtained  from  the  applicable  tasks  that 
relate  to  the  capability  gap  are  used  to  develop  lower  level  measures  of  effectiveness  and 
performance  that  will  be  used  to  evaluate  system  requirements.  Thus,  when  looking  at  the 
ISR  MAV,  key  parameters  are  identified  that  will  help  determine  the  level  to  which  ISR 
MAVs  fill  the  gap.  Architectures  provide  a  powerful  tool  that  can  be  used  to  help  define 
parameters  throughout  system  design. 

In  this  thesis,  traceability  efforts  started  at  the  top  of  the  DoD  capability  hierarchy. 
To  facilitate  understandable  requirements  decomposition,  two  parallel  approaches  were 
used  to  determine  where  the  capability  gaps  existed.  The  first  approach  looked  at  the 
organizational  mission  areas  of  the  using  commands.  Starting  at  the  national  level,  each 
organization’s  mission  statement  was  reviewed  and  traced  to  its  sub  levels;  leading  to 
the  primary  ISR  MAV  mission  areas.  The  concurrent  approach  looked  at  the  Air  Force 
Task  List  (AFTL)  to  determine  which  tasks  that  the  ISR  MAV  would  support  through  the 
AFTL  hierarchy.  Since  the  ISR  MAV  missions,  described  in  Chapter  IV,  describe  Air 
Force  focused  missions,  AFTL  tasks  were  used  in  lieu  of  tasks  from  the  Universal  Joint 
Task  List  (UJTL).  However,  the  AFTL  resides  at  the  tactical-level  of  the  UJTL. 

Once  the  operational  scenarios  were  linked  to  identified  capability  gaps  and 
missions,  the  next  steps  were  to  review  the  given  scenarios  and  corresponding  AFTL’s  for 
a  tailored  list  of  measures.  These  measures  represent  the  characteristics  that  an  accepted 
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concept  must  embody  as  a  solution  to  the  capability  gap,  and  that  would  be  necessary  to 
effectively  evaluate  the  system’s  performance.  While  the  AFTLs  provide  some  top-level 
measures  for  comparing  different  concepts,  further  refinement  must  be  accomplished  in 
order  to  provide  that  would  be  useful  in  describing  a  tactical  MAV  system.  Therefore, 
several  other  specific  measures  were  developed  for  the  ISR  MAV. 

This  chain  of  decomposition  from  national-level  missions  to  scenarios,  to  measures 
now  provides  traceability  to  the  ultimate  system’s  testable  configuration.  From  the 
scenarios  and  measures,  an  integrated  architecture  can  be  produced  to  facilitate  that 
testable  design.  The  integrated  architecture  will  also  aid  in  developing  the  necessary 
system  requirements  to  develop  the  actual  system  that  will  be  evaluated  by  the  list  of 
system  measures.  Throughout  the  architecture  design,  traceability  plays  a  key  role. 
Many  parts  of  the  architecture  must  relate  to  and  trace  similar  objects  to  other  parts  of 
the  architecture.  The  next  few  sections  describe  an  integrated  architecture  in  detail  and 
traceability  is  a  present  and  a  necessary  attribute  to  validate  the  final  architecture. 

3.2  Architectural  Views 

While  traceability  describes  the  connections  that  should  be  maintained  while 
describing  a  system  in  many  different  views,  an  architecture  is  a  way  of  organizing  those 
views. 


“An  architecture  is  the  fundamental  organization  of  a  system  embodied  in  its 
components,  their  relationships  to  each  other,  and  to  the  environment,  and  the 
principles  guiding  its  design  and  evolution”  [28]. 

A  well  understood  system  depends  not  only  on  comprehending  the  information  contained 
within  each  view,  but  also  the  framework  in  which  the  view  was  created.  The  system 
designer  and  user  of  the  various  architectural  views  benefit  from  first  understanding  what 
a  specific  architectural  view  is  designed  to  present  and  how  the  specific  system  should  be 
instantiated  from  that  view.  Then  both  parties  can  read  the  information  together  and  also 
understand  the  context  in  which  the  system  has  been  placed. 
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An  architecture  can  only  be  defined  as  integrated  when  its  products  and  their 
components  are  developed  such  that  the  components  defined  in  one  view  are  the  same 
(same  names,  definitions,  and  values)  as  those  referenced  in  another  view  [24:1-1].  In 
terms  of  the  three  architectural  views,  an  integrated  architecture  refers  to  an  architecture 
description  that  has  integrated  the  operational,  system,  and  technical  standards  views. 
With  a  properly  integrated  architecture,  complex  systems  are  better  understood  by  the 
users,  engineers,  designers,  maintainers,  etc.  This  increased  understanding  ensures  that 
the  system  properly  integrates  with  other  systems  or  external  systems  (external  systems 
are  those  systems  that  are  outside  of  the  design  boundary  but  are  needed  in  order  for  the 
designed  system  to  function  properly). 

3.2.1  DoD  Architecture  Framework.  As  with  many  major  written  products, 
guidelines  or  style  guides  exist  to  frame  the  architecture.  Several  sets  of  guidelines  are 
available  detailing  how  to  architect  a  system.  In  the  1950’s,  the  Structured  Analysis  and 
Design  Technique  (SADT)  was  created.  A  combination  of  several  separate  but  related 
techniques;  it  was  a  process-focused  approach  and  works  very  well  with  the  design  of 
physical  systems.  The  SADT  was  used  initially  in  the  formation  of  a  Command,  Control, 
Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR) 
architecture  framework  by  and  for  the  development  of  C4ISR  systems  in  1997. 

Through  the  past  few  decades,  a  different  architecting  construct  also  emerged  from 
the  software  development  community.  The  Object-Oriented  (00)  method,  which  viewed 
systems  in  more  of  a  data-centered  approach,  showed  that  it  was  very  useful  with  the 
growing  use  of  software-dependent  systems  within  the  DoD.  In  an  effort  to  correlate 
both  the  SADT  and  00  approaches,  [8]  a  DoD  working  group  built  upon  the  C4ISR 
Architecture  Framework  to  form  a  DoD-wide  standard  for  architecture  development.  It  is 
called  the  DoD  Architecture  Framework  1.0  (DoDAF).  It  gives  descriptions,  examples, 
and  templates  from  both  the  SADT  and  00  approaches  in  producing  the  neccessary 
products  for  an  integrated  architecture.  For  this  thesis,  DoDAF  was  used  as  the  guiding 
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instruction  for  producing  architectural  views.  DoDAF  gives  the  following  description  of 
architectures. 


An  architecture  description  is  a  representation  of  a  defined  domain,  as  of  a 
current  or  future  point  in  time,  in  terms  of  its  constituent  parts,  what  those 
parts  do,  how  the  parts  relate  to  each  other  and  to  the  environment,  and 
the  rules  and  constraints  governing  them.  Within  the  DoDAF,  architectures 
are  described  in  terms  of  three  views:  Operational  View  (OV),  Systems 
View  (SV),  and  Technical  Standards  View  (TV).  An  architecture  description 
is  composed  of  architecture  products  that  are  interrelated  within  each  view 
and  are  interrelated  across  views.  Architecture  products  are  those  graphical, 
textual,  and  tabular  items  that  are  developed  in  the  course  of  gathering 
architecture  data,  identifying  their  composition  into  related  architecture 
components  or  composites,  and  modeling  the  relationships  among  those 
composites  to  describe  characteristics  pertinent  to  the  architecture’s  intended 
use.  [24:1-1] 

DoDAF  is  composed  of  over  26  specific  products,  each  product  serving  a  separate 
purpose  with  different  perspectives  and  layers  of  detail.  As  mentioned  above  by  the 
DoDAF,  the  products  are  grouped  within  three  main  category  views:  Operational  View 
(OV),  Systems  View  (SV),  and  Technical  Standards  View  (TV). 

“The  OV  contains  graphical  and  textual  products  that  comprise  an  identification  of 
the  operational  nodes  and  elements,  assigned  tasks  and  activities,  and  information  flows 
required  between  nodes.  It  defines  the  types  of  information  exchanged,  the  frequency  of 
exchange,  which  tasks  and  activities  are  supported  by  the  information  exchanges,  and  the 
nature  of  information  exchanges”  [24:2-1].  The  specific  views  within  the  OV  represent 
the  operational  functionality  of  the  system.  Its  views  concentrate  more  on  the  functions 
and  tasks  that  a  system  must  perform  in  order  to  meet  the  overall  user  requirements. 

“The  SV  associates  system  resources  to  the  OV.  These  system  resources  support 
the  operational  activities  and  facilitate  the  exchange  of  information  among  operational 
nodes”  [24:2-2].  The  specific  views  within  the  SV  begin  to  give  the  system  a  form.  It 
builds  on  the  functions  designed  in  the  OV’s  and  assigns  actual  systems  to  perform  those 
tasks. 
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“The  TV  includes  a  collection  of  the  technical  standards,  implementation 
conventions,  standards  options,  rules,  and  criteria  organized  into  profile(s)  that  govern 
systems  and  system  elements  for  a  given  architecture”  [24:2-2].  The  specific  views  within 
the  TV  give  the  reader  the  lowest  level  of  detail  when  it  comes  to  the  actual  specifications 
that  the  system  design  will  either  be  built  to  or  need  to  adhere  to.  Figure  3.1  shows  how 
the  views  are  linked. 

Understanding  how  the  views  cover  their  respective  areas  and  interact  with  one 
another  helps  in  understanding  the  specific  views.  When  one  is  looking  at  an  OV,  they 
should  be  thinking  what  is  or  needs  to  be  done,  but  also  that  an  SV  and  a  TV  will  tell  them 
what  will  do  it  and  in  what  detailed  way  it  will  be  done  respectively. 
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Figure  3.1  Fundamental  Linkages  Between  Views 


3.2.2  Modeling  Languages.  Now  that  the  general  makeup  of  an  architecture  is 
understood,  their  creation  and  languages  can  be  discussed.  Modeling  languages  used  for 
architectures  are  similar  to  spoken  languages.  Two  people  speaking  in  different  languages 
can  compose  and  speak  a  sentence  communicating  the  same  thought.  Regardless  of 
the  form  that  each  word  takes,  there  still  needs  to  be  basic  elements  represented  (i.e. 
nouns,  verbs,  articles).  Similarly,  modeling  languages  may  appear  different  and  use 
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different  approaches,  but  they  can  represent  the  same  system  through  use  of  common 
elements.  Within  the  systems  engineering  community  DoDAF,  there  are  two  sets  of 
modeling  languages  that  are  generally  accepted  in  producing  architectural  views.  These 
are  the  Unified  Modeling  Language  (UML)  and  Integrated  Computer  Aided  Manufac¬ 
turing  (ICAM)  Definition  (IDEF). 

UML  employs  the  object-oriented  (00)  approach  which  is  “a  general-purpose 
modeling  language  for  specifying,  visualizing,  constructing  and  documenting  the  artifacts 
of  software  systems,  as  well  as  for  business  modeling  and  other  non-software  systems” 
[34].  UML  is  widely  accepted  within  the  software  development  community  it  originated 
from.  By  focusing  on  the  data  elements  and  rule  modeling  needed  to  perform  use- 
case  scenarios,  UML  products  work  relatively  easily  into  the  executable  software  realm. 
Initally  not  included  in  the  development  of  the  C4ISR  architecture,  Doctors  Michael 
Bienvenu,  Insub  Shin,  and  Alexander  Levis  showed  that  UML  could  be  used  to  produce 
the  required  products  for  that  architecture  [8].  It  is  evident  in  the  fact  that  DoDAF  now 
includes  UMF  as  an  accepted  method  of  producing  its  products. 

IDEF  uses  the  structured  analysis  (SA)  approach  to  produce  its  views.  The  SA 
approach  uses  the  system’s  activities  and  functions  being  performed  as  the  building  blocks 
of  their  views.  The  SA  method  builds  upon  two  types  of  architecture  constructs:  the 
functional  architecture  and  the  physical  architecture.  “A  functional  architecture  is  a  set  of 
activities  or  functions,  arranged  in  a  specified  partial  order  that,  when  activated,  achieves 
a  set  of  requirements.  Similarly,  a  physical  architecture  is  a  representation  of  the  physical 
resources,  expressed  as  nodes,  that  constitute  the  system  and  their  connectivity,  expressed 
in  the  form  of  links”  [31:228].  To  create  these  two  architectures  there  are  several  IDEF 
variants  that  focus  on  different  areas  of  systems  analysis.  IDEFO  is  a  function  modeling 
method  that  focuses  on  the  activities  of  a  system.  IDEFlx  is  a  data-modeling  method 
that  looks  at  a  system  as  a  collection  of  interacting  data  packages.  IDEF3  is  a  process 
description  capture  method  that  focuses  on  how  the  system  operates  through  actions  and 
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events  [4].  There  are  a  few  others  as  well,  though  they  will  not  be  used  in  the  architectural 
products  produced  in  this  thesis. 

Since  the  ISR  MAV  is  a  physical  system  and  the  UML  language  does  not  work 
ideally  outside  of  the  purely  software  environment,  the  SA  approach  through  IDEF 
languages  is  used  to  produce  the  required  architectural  views.  The  SA  approach  and 
its  functional  and  physical  architectures  relate  very  well  to  the  DoDAF  standard.  The 
SA  functional  architecture  and  the  DoDAF  operational  view  are  related  in  their  role  and 
representations.  The  SE  physical  architecture  and  the  DoDAF  systems  view  are  also 
closely  related  in  how  they  convey  a  system  design  in  the  integrated  architecture. 

3.2.3  Architectural  Products.  An  integrated  architecture  is  composed  of  several 
views,  each  represented  by  several  distinct  products.  The  DoDAF  contains  over  26 
types  of  products,  each  with  its  own  viewpoint  and  types  of  elements  represented.  In 
the  DoD,  the  Joint  Capabilities  Integration  and  Development  System  (JCIDS)  process 
directs  integrated  architectures  and  provides  guidelines  on  what  architectural  products  are 


Table  3.1  JCIDS  Required  Products 


Product 

Title 

AV-1 

Overview  and  Summary  Information 

AV-2 

Integrated  Dictionary 

OV-1 

High-Fevel  Operational  Concept  Graphic 

OV-2 

Operational  Node  Connectivity  Diagram 

OV-3 

Operational  Information  Exchange  Matrix* 

OV-4 

Organizational  Relationships  Chart 

OV-5 

Operational  Activity  Model 

OV-6C 

Operational  Event  Trace  Description 

SV-1 

Systems  Interface  Description* 

SV-4 

Systems  Functionality  Description 

SV-5 

Operational  Activity  to  Systems  Functionality  Traceability  Matrix 

SV-6 

Systems  Data  Exchange  Matrix 

required  and  when.  Treating  this  research  in  much  the  same  as  a  Capability  Development 
Document  (CDD),  the  architectural  products  required  for  it  were  reviewed  for  a  baseline 
[14:E-A-6].  Then  looking  ahead  to  the  requirements  for  the  next  milestone,  the  minimum 
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required  products  for  the  CPD  were  used.  These  minimum  products  required  by  JCIDS 
policy  for  systems  with  top-level  information  exchange  requirements  in  the  Capability 
Production  Document  (CPD)  [14]  are  listed  in  table  3.1. 


In  addition,  the  OV-7:  Logical  Data  Model  was  developed  because  this  product 
gives  the  best  understanding  of  the  actual  data  elements  that  pertain  to  the  system.  Each 
of  the  aforementioned  products  are  explained  below,  including  their  DoDAF  definitions, 
examples,  and  reasons  why  they  are  important  for  understanding  the  system. 


AV-1  -  Overview  and  Summary  Information.  The  AV-1  (Figure  3.2)  provides 
executive-level  summary  information  in  a  consistent  form  that  allows  quick  reference 
and  comparison  among  architectures.  The  AV-1  includes  assumptions,  constraints,  and 


•  Architecture  Project  Identification 

-  Name 

-  Architect 

-  Organization  Developing  the  Architecture 

-  Assumptions  and  Constraints 

-  Approval  Authority 

-  Date  Completed 

-  Level  of  Effort  and  Projected  and  Actual  Costs  to  Develop  the  Architecture 

•  Scope:  Architecture  Yiew(s)  and  Products  Identification 

-  Views  and  Products  Developed 

-  Time  Frames  Addressed 

-  Organizations  Involved 

•  Purpose  and  Viewpoint 

-  Purpose,  Analysis,  Questions  to  be  Answered  by  Analysis  of  the  Architecture 

-  From  Whose  Viewpoint  the  Architecture  is  Developed 

•  Context 

-  Mission 

-  Doctrine,  Goals,  and  Vision 

-  Rules,  Criteria,  and  Conventions  Followed 

-  Tasking  for  Architecture  Project  and  Linkages  to  Other  Architectures 

•  Tools  and  File  Formats  Used 

•  Findings 

-  Analysis  Results 

-  Recommendations _ 


Figure  3.2  AV-1  -  Template 


limitations  that  may  affect  high-level  decision  processes  involving  the  architecture  [24:3- 
1].  This  product  is  considered  the  title  page  of  the  architecture,  and  gives  the  reader  a 
high-level  overview  of  the  following  architecture. 


AV-2  -  Integrated  Dictionary.  This  product  contains  definitions  of  terms  used  in  the 
given  architecture.  It  consists  of  textual  definitions  in  the  form  of  a  glossary,  a  repository 
of  architecture  data,  their  taxonomies,  and  their  metadata  (i.e.,  data  about  architecture 
data),  including  metadata  for  tailored  products,  associated  with  the  architecture  products 
developed.  Metadata  are  the  architecture  data  types,  possibly  expressed  in  the  form  of 
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a  physical  schema  [24:3-9].  This  product  is  critical  for  traceability  between  all  of  the 
architecture  products. 

As  the  name  dictionary  infers,  one  should  be  able  to  use  the  AV-2  as  a  reference  to 
understand  the  other  products.  Every  data  element  or  object  found  in  each  of  the  products 
should  also  be  found  defined  in  the  AV-2.  As  an  integrated  dictionary,  it  also  needs  to 
relate  the  objects  and  the  products  so  that  the  architectural  products  are  tied  together. 
Objects  found  in  more  than  one  product  should  have  the  same  definition.  An  integrated 
dictionary  can  take  many  forms,  but  basic  information  about  the  data  elements  within 
should  be  consistent  and  as  complete  as  possible  to  aid  understanding  of  the  element.  The 
goals  of  this  product  are  to  document  the  architecture’s  contents,  show  their  relation  to 
one  another,  and,  if  necessary,  serve  as  a  textural  representation  of  the  entire  architecture. 

OV-1  -  High-Level  Operational  Concept  Graphic.  The  OV-1,  an  example  of 
which  is  shown  in  Figure  3.3,  describes  a  mission  and  highlights  the  main  operational 


Figure  3.3  OV-1  -  Example 


nodes  and  interesting  or  unique  aspects  of  operations.  It  provides  a  description  of 
the  interactions  between  the  subject  architecture  and  its  environment,  and  between  the 
architecture  and  external  systems.  A  textual  description  accompanying  the  graphic  is 
crucial.  Graphics  alone  are  not  sufficient  for  capturing  the  necessary  architecture  data  [24: 
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4-1].  This  product  gives  the  reader  a  very  basic,  but  operationally  complete  view  of  the 
system  and  is  typically  used  in  presentations  to  introduce  the  system  and  promote  initial 
understanding.  The  OV-1  is  particularly  useful  in  communicating  the  unique  aspects  of 
the  system  to  individuals  unfamiliar  with  the  system  or  architecture  being  discussed. 

OV-2  -  Operational  Node  Connectivity  Diagram.  This  product,  and  example  of 
which  is  shown  in  Figure  3.4,  graphically  depicts  the  operational  nodes  (or  organizations) 
with  needlines  between  those  nodes  that  indicate  a  need  to  exchange  information.  The 
graphic  includes  internal  operational  nodes  (internal  to  the  architecture)  as  well  as  external 
nodes  [24:4-7]. 

As  one  of  the  first  products  to  be  created  in  constructing  an  architecture,  this  product 
helps  to  shape  the  system  model.  It  breaks  the  system  into  its  most  basic  major  players  so 


Xeedline 

Information  Type  W 


External 
Destination  L 


Information  Type  Z 


External 
Source  M 


Figure  3.4  OV-2  -  Template 


that  needlines  of  information,  major  interfaces,  and  areas  of  responsibility  are  broken  out 
early.  Much  of  the  rest  of  the  architecture  is  based  directly  on  how  the  nodes  and  needlines 
interact. 

OV-3  -  Operational  Information  Exchange  Matrix.  This  product  details 
information  exchanges  and  identifies  “who  exchanges  what  information,  with  whom,  why 
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the  information  is  necessary,  and  how  the  information  exchange  must  occur”  [15].  There 
is  not  a  one-to-one  mapping  of  OV-3  information  exchanges  to  OV-2  needlines;  rather, 
many  individual  information  exchanges  may  be  associated  with  one  needline  [24:4-16]. 

Figure  3.5  shows  representative  column  headings  for  a  typical  OV-3  table.  The 
rows  list  the  OV-2  needlines  and  their  sub  information  exchanges.  The  column  headings 


Figure  3.5  OV-3  -  Template 

are  generally  tailored  to  the  specific  system  type  being  modeled.  For  example,  a  template 
for  a  complex  communication  system  will  have  more  columns  than  a  simpler  system  with 
few  information  exchanges.  For  this  research  the  column  headings  with  their  meanings  as 
defined  by  DoDAF  [24]  has  been  provided  in  Appendix  F. 

OV-4  -  Organization  Relationships  Chart.  This  product  illustrates  the  command 
structure  or  relationships  among  human  roles,  organizations,  or  organization  types  that  are 
the  key  players  in  an  architecture  [24:4-27].  Many  times  this  is  a  hierarchal  organization 
chart  illustrating  the  levels  and  layers  of  command  interacting  with  the  system.  It  is  useful 
not  only  to  understand  the  players  with  respect  to  the  actual  system,  but  also  with  the 
architecture  itself.  Many  times  this  product  has  few,  if  any,  direct  links  to  other  products; 
however,  it  is  a  valuable  perspective  of  the  organizational  environment  in  which  the  system 
is  designed,  acquired  and  operated. 
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Figure  3.6  OV-4  -  Template 


OV-5  -  Operational  Activity  Model.  The  OV-5  describes  the  operations  that 
are  normally  conducted  in  the  course  of  achieving  a  mission  or  a  business  goal.  It 
describes  capabilities,  operational  activities  (or  tasks),  input  and  output  (I/O)  flows 
between  activities,  and  I/O  flows  to/from  activities  that  are  outside  the  scope  of  the 
architecture  [24:4-31]. 
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Figure  3.7  OV-5  -  Template 


This  product  shows  the  functional  interaction  of  the  system.  It  gives  insight  into 
what  the  system,  and  its  subsystems,  takes  in  as  inputs  and  controls,  and  what  mechanisms 
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it  uses  to  produce  outputs.  This  product  is  produced  in  hierarchical  form,  meaning  that 
each  view  can  be  decomposed  into  children  views  to  show  sub  function  interaction.  The 
product  is  represented  in  either  its  hierarchal  form  or  its  flow  diagram  form  in  which  the 
inputs,  controls,  outputs,  and  mechanisms  (ICOMs)  show  their  interaction.  This  product 
is  important  for  original  capability  decomposition,  and  also  in  understanding  how  the  sub 
functions  and  activities  interact.  For  this  research,  the  language  IDEFO  was  used  to  create 
this  product.  Many  times  the  ICOMs  serve  as  a  basis  for  system  requirements  generation. 


Control 


Activity 


Mechanism 


Figure  3.8  ICOM  Notation 


Figure  3.8  shows  the  standard  notation  for  using  ICOMs  in  an  operational  Activity 
Model.  Inputs  are  depicted  as  entering  the  function  box  from  the  left,  Controls  entering 
from  the  top,  outputs  exiting  the  function  and  going  to  the  right,  and  mechanisms  entering 
the  function  from  the  bottom.  ICOMS  that  enter  or  exit  the  function  box  at  one  level 
should  also  appear  on  any  higher  or  lower  level  decomposition  of  that  function.  For  cases 
where  readability  is  an  issue  and  a  certain  ICOM  is  not  required  for  understanding  at 
another  level,  it  may  be  tunneled.  This  is  indicated  by  parentheses  placed  around  the  head 
(entering)  or  tail  (exiting)  ICOM  to  be  tunneled. 
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OV-6C  -  Operational  Event  Trace  Description.  The  OV-6C  provides  a  time- 
ordered  examination  of  the  information  exchanges  between  participating  operational 
nodes  as  a  result  of  a  particular  scenario.  Each  event-trace  diagram  should  have  an 
accompanying  description  that  defines  the  particular  scenario  or  situation  [24:4-55].  It 
essentially  takes  the  major  nodes  from  the  OV-2  and  turns  them  into  swim  lanes  within 
which  the  actions  of  the  scenarios  are  played  out. 


Figure  3.9  OV-6c  -  IDEF3  Example 


The  purpose  of  the  OV-6C  is  to  show  the  critical  path(s)  through  a  given  scenario. 
While  in  other  products  the  connector  lines  many  times  represent  communication,  info,  or 
needlines,  in  this  view  they  are  only  precedent  links  that  allow  subsequent  tasks  to  take 
place.  Junctions  are  also  used  to  illustrate  alternated  paths.  Each  action  is  also  traced  to 
functions  on  the  OV-5.  Once  this  product  is  made,  it  is  easy  to  validate  each  action  in  the 
OV-6  with  a  function  from  the  OV-5.  For  this  research,  the  language  IDEF3  was  used  to 
create  this  product. 

OV-7  -  Logical  Data  Model.  The  OV-7  describes  the  structure  of  an  architecture 
domain’s  system  data  types  and  the  structural  business  process  rules  (defined  in  the 
architecture’s  Operational  View)  that  govern  the  system  data.  It  provides  a  definition 
of  architecture  domain  data  types,  their  attributes  or  characteristics,  and  their  interrela¬ 
tionships  [24:4-62].  While  not  a  specifically  required  product  for  the  CDD  per  CJCSM 
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3170,  the  OV-7  is  included  because  of  its  importance  to  any  system  design  effort  where 
software  is  involved. 

The  system’s  ICOM’s,  found  in  the  OV-5,  are  represented  in  the  OV-7  as  either 
individual  data  types,  or  as  attributes  within  other  data  types.  The  OV-7  can  be  used  by  the 
software  development  effort,  therefore  the  diagram  deals  in  what  types  and  links  of  data 
must  be  present  for  the  system  to  operate.  The  developers  can  then  use  this  information 
to  develop  the  actual  programming  and  coding  of  the  software  portion  of  the  system.  For 
this  research,  the  language  IDEFlx  was  used  to  create  this  product. 

Relationships  represented  in  an  OV-7  serve  to  show  how  one  data  entity,  or  data 
package,  depends  on  other  packages.  Attributes  in  some  packages  are  required  by  other 
packages  to  identify  a  specific  instantiation  of  the  data.  These  identifying  attributes  are 
called  primary  keys.  When  a  data  package  depends  on  another  package,  the  primary  key 
is  translated  to  the  depending  package  as  a  primary  foreign  key. 


Figure  3.10  OV-7  -  Template 

There  are  also  relationships  of  a  hierarchical  nature,  where  data  packages  linked  to  a 
higher-level  package  contain  all  of  the  attributes  of  the  higher  package  with  the  addition  of 
one  specifically  listed  in  the  lower-level  packages.  This  relationship  is  represented  as  the 
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lower-level  packages  bracketing  into  a  circle  with  a  short  line  over  it  and  a  line  out  of  this 
symbol  goes  to  the  higher- level  package.  Any  relationships  to  the  higher- level  package 
automatically  exist  to  the  lower-level  packages. 

Required  attributes  are  shown  in  bold.  Multiplicity  of  certain  data  packages  are 
labeled  on  the  relationship  links.  They  indicate  the  acceptable  number  of  instantiations  of 
the  data  package  that  the  relationship  supports. 

SV-1  -  Systems  Interface  Description.  The  SV-1  depicts  systems  nodes  and  the 
systems  resident  at  these  nodes  to  support  organizations  and/or  human  roles  represented 
by  operational  nodes  of  the  Operational  Node  Connectivity  Description  (OV-2).  SV-1 
also  identifies  the  interfaces  between  systems  and  systems  nodes  [24:5-1].  As  the  first 
product  within  the  systems  view,  the  S V- 1  is  important  because  it  begins  the  process  of 
forming  the  operational  view  of  the  system  into  an  actual  physical  system.  Operational 
nodes  and  activities  from  the  operational  view  are  translated  and  transformed  into  systems 
and  system  functions.  The  SV-1  begins  that  process  through  its  assignment  of  system 
functional  responsibility  among  the  nodes  and  interfaces. 

Several  versions  of  the  System  Interface  Description,  as  shown  in  Figures  3.11 
through  3.14,  can  be  developed  to  show  various  levels  of  detail  for  the  system  under 
design.  The  SV-1  may  represent  the  internodal  view  of  the  system  showing  node  to  node 


Figure  3.11  SV-1  a  -  Internodal  Template  Showing  Node  Interfaces 

interfaces  (Figure  3.11),  system  to  system  interfaces  (Figure  3.12),  interfaces  within  each 
node  (Figure  3.13),  or  an  intrasystem  view  showing  hardware  and  software  items  within 
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Figure  3.12  SV-lb  -  Intemodal  Template  Showing  System  Interfaces 
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Figure  3.13  SV-lc  -  Intranodal  Template 


each  node  (Figure  3.14).  While  the  DoDAF  does  not  distinguish  between  the  various 
versions  other  than  by  name,  for  the  purposes  of  this  thesis,  they  will  be  referred  to  as  an 
SV-la,  SV-lb,  SV-lc  and  SV-ld  respectively. 

The  SV-la  provides  a  generic  intemodal  view  that  illustrates  node  to  node  interfaces. 
The  applicable  systems  that  make  up  each  node  are  shown  but  the  system-to-system 
interfaces  are  withheld.  Additional  information,  such  as  system  functions,  can  also  be 
included  in  each  of  the  nodes  should  the  architect  find  this  information  useful  in  clarifying 
the  view.  The  SV-lb  expands  on  the  SV-la  by  providing  the  interfaces  from  the  node 
boundaries  to  each  system  contained  therein.  The  intranodal  version,  or  SV-lc,  provides 
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Figure  3.14  SV-ld  -  Intrasystem  Example 


a  detailed  look  at  each  node  by  showing  interfaces  between  systems  within  the  nodal 
boundaries  and  can  include  references  to  each  system  if  desired.  Finally,  the  SV-ld 
intrasystem  view  shows  systems  hardware  and  software  that  interface  within  each  node 
and  provides  a  more  detailed  view  that  begins  to  resemble  a  physical  system. 

SV-4  -  Systems  Functionality  Description.  The  SV-4  documents  system  functional 
hierarchies,  system  functions  and  the  system  data  flows  between  them.  Although  there  is 
a  correlation  between  the  Operational  Activity  Model  (OV-5)  and  the  system  functional 


Figure  3.15  SV-4  -  Template  (Data  Flow  Diagram) 

hierarchy  of  SV-4,  it  need  not  be  a  one-to-one  mapping,  hence,  the  need  for  the  Operational 
Activity  to  Systems  Function  Traceability  Matrix  (SV-5),  which  provides  that  mapping 
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[24:5-25].  In  the  way  that  the  OV-5  decomposed  and  related  its  activities  in  the  operational 
view,  the  SV-4  takes  the  system  functions  from  the  SV-1  and  decomposes  and  relates  them. 
One  difference  between  the  OV-5  and  SV-4  is  that  the  former  looks  at  the  entire  system’s 
activities,  while  the  latter’s  primary  focus  is  on  data  exchange. 

The  view  takes  one  more  step  in  the  systems  view  to  assigning  functional  responsi¬ 
bilities  to  systems  and  subsystems.  The  data  that  moves  between  SV-4  functions  are  more 
exact  in  nature  than  were  found  in  the  operational  view.  These  data  links  are  described 
in  much  detail  in  the  Systems  Data  Exchange  Matrix  (SV-6),  and  will  be  ultimately  used 
in  the  actual  design  of  subsystem  interface  specifications.  Similar  to  the  OV-5,  the  SV-4 
is  also  hierarchal,  so  each  function  can  be  broken  down  into  its  children  views.  In  other 
words,  unlike  the  OV-5  where  ICOMs  enter  and  leave  views  without  reference  to  their 
origin  or  destinations,  the  SV-4  shows  the  data  exchange  lines  coming  from  or  going  to 
their  external  systems  or  other  subsystem  functions. 

SV-5  -  Operational  Activity  to  Systems  Function  Traceability  Matrix.  The  SV- 

5  provides  a  specification  of  the  relationships  between  the  set  of  operational  activities 
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applicable  to  an  architecture  and  the  set  of  system  functions  applicable  to  that  architecture 
[24:5-35].  This  product  is  useful  in  ensuring  the  architecture’s  traceability.  It  serves  as  a 
feedback  mechanism  to  the  original  requirements  and  provides  a  link  between  the  OV-5 
and  SV-4  products.  It  is  important  to  ensure  that  the  activities  designed  in  the  operational 
view  are  accounted  for  in  the  system  view  in  some  form  of  function.  This  also  helps  justify 
why  system  functions  are  present  in  the  system  view  and  to  determine  any  unwarranted 
functions. 

SV-6  -  Systems  Data  Exchange  Matrix.  The  SV-6  specifies  the  characteristics 
of  the  system  data  exchanged  between  systems  and  focuses  on  automated  information 
exchanges  (from  OV-3)  that  are  implemented  in  systems.  Non-automated  information 
exchanges,  such  as  verbal  orders,  are  captured  in  the  OV  products  only  [24:5-41].  This 
product  gives  a  great  deal  of  detail  about  the  data  exchanges  that  have  been  designed  in 
the  system  view.  This  matrix  accounts  for  all  of  them  and  will  serve  as  a  link  to  the 
technical  standards  view  when  actual  subsystem  and  component  interface  descriptions  are 
determined. 

As  with  the  OV-3  Operational  Exchange  Matrix,  the  column  headings  are  generally 
tailored  to  the  specific  system  type  being  modeled.  For  this  research  the  column  headings 
with  their  meanings  as  defined  by  DoDAF  [24]  have  been  provided  in  Appendix  N. 
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IV.  Results 


This  chapter  begins  with  an  analysis  of  the  three  mission  scenarios  (over-the-hill 
reconnaissance,  battle  damage  information  and  local  area  defense),  focusing  on  the  entry 
conditions  and  a  typical  mission  profile  for  each  scenario.  Following  the  mission  scenario 
analysis  are  the  traceability  results  that  seek  to  tie  the  missions,  and  ensuing  architectures, 
to  specific  Air  Force  tasks.  Inherent  with  the  identified  tasks  are  associated  measures  that 
can  be  used  to  determine  the  degree  to  which  MAVs  accomplish  those  tasks.  Additionally, 
the  aforementioned  scenarios  have  potential  ties  to  the  Joint  Functional  Concepts  (JFC). 
While  traceability  to  JFCs  was  not  performed  for  this  project,  the  act  of  performing  this 
additional  analysis  can  provide  additional  insights  into  areas  where  the  use  of  MAVs 
would  prove  valuable.  Chapter  III  presented  the  generic  format  for  the  Department  of 
Defense  Architecture  Framework  (DoDAF)  products  whereas  this  chapter  presents  the 
architectural  products  developed  for  the  ISR  MAV.  A  discussion  on  the  impacts  MAVs 
have  on  doctrine,  organization,  training,  material,  leadership/education,  personnel  and 
facilities  (DOTMLPF)  is  then  presented  followed  by  an  examination  of  future  MAV 
capabilities  related  to  technology  and  operational  use  as  constrained  by  the  scope  and 
architectures  used  to  define  ISR  MAVs. 

4.1  Operational  Scenarios 

Three  operational  scenarios  were  developed  that  are  related  to  both  the  applicable 
special  operations  forces  core  tasks  and  capability  deficiencies  outlined  in  Sections  2.1.2 
and  2.1.3.  A  description  of  each  operational  scenario  is  provided  that  includes  entry 
conditions  and  pertinent  information  regarding  key  operational  aspects  of  the  employment 
of  MAVs  and  their  ability  to  provide  unit-level,  close  proximity,  actionable  intelligence. 
From  these  scenarios,  a  list  of  requirements  can  begin  to  be  formulated.  However, 
the  MAV  architecture  provides  for  more  in-depth  requirements  analysis  and  refinement. 
While  this  analysis  was  not  specifically  performed,  a  brief  discussion  of  the  merits  of 
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using  architectures  to  develop  and  refine  requirements  and  their  associated  measures  will 
be  provided  in  Chapter  V. 

4.1.1  Over-the-Hill  Reconnaissance.  In  this  mission,  the  MAV  enhances  a 
special  operations  team’s  situational  awareness  of  their  immediate  surroundings.  The  set¬ 
up  for  this  mission  assumes  that  a  small  friendly  force  is  on  a  patrol  mission  into  uncleared 
territory.  The  patrol  moves  to  a  specific  location  without  full  advance  intelligence  of  the 
area  they  are  moving  through.  The  mission  scenario  also  includes  the  team  reaching  their 
objective  location  and  performing  surveillance  while  concealed. 

The  entry  condition  to  this  scenario  starts  with  a  friendly  team  members’  decision 
to  obtain  local  area  reconnaissance  above  the  team’s  current  location  or  areas  they  are 
moving  into.  The  MAV  is  at  hand  and  is  launched  after  its  prep  time.  It  is  flown  either 
manually  or  automatically  using  a  looping  area  search  pattern  above  the  team’s  location 
(or  slightly  ahead  of  the  team).  The  operator  observes  the  video  feedback  from  the  MAV 
thus  enhancing  the  team’s  situational  awareness.  Should  the  operator  observe  an  enemy 
presence,  the  video  feed  with  accompanying  geo-location  information  can  be  relayed  to 
those  requiring  the  information  to  possibly  attack  the  enemy  location.  The  decision  to 
relay  this  information  is  purely  up  to  operator  discretion  (i.e.  not  an  automatic  link).  A 
similar  use  of  the  MAV  occurs  once  reaching  their  objective  location  and  the  team  decides 
to  better  observe  their  target. 

Throughout  the  flight  time  of  the  MAV,  the  video  feedback  should  enable  operating 
personnel  a  suitable  level  of  target  discrimination  to  positively  identify  key  characteristics 
of  enemy  and  their  equipment.  Examples  might  be  discriminating  between  major  objects, 
vehicles,  buildings,  and  weapon  systems.  Once  the  MAV  obtains  sufficient  information 
in  the  team’s  general  vicinity,  or  the  MAV  limits  are  reached,  the  operator  can  either 
return  the  MAV  to  the  base  or  choose  to  continue  loitering  the  MAV  until  complete  power 
failure  (i.e.  expend  the  MAV).  Assuming  the  MAV  returns  and  is  recovered,  the  SOF  team 
refuels/recharges  the  MAV  for  immediate  further  flights  or  stores  the  MAV  for  travel. 
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4.1.2  Battle  Damage  Information.  In  this  mission,  the  MAV  is  used  to  gather 
battle  damage  information  following  an  attack  on  an  enemy  location.  The  set-up  for  this 
mission  assumes  that  a  friendly  force  patrol  already  knows  the  location  of  an  enemy  and 
has  already  launched  or  is  currently  launching  a  strike  on  the  enemy.  The  strike  could  be  a 
called-in  air  strike,  a  called-in  artillery  attack,  or  a  direct  attack  from  their  current  location. 
The  team  is  close  enough  to  the  enemy  location  that  the  MAV  is  within  range. 

The  entry  condition  to  this  scenario  starts  with  a  friendly  team  member’s  decision 
to  obtain  Battle  Damage  Information  (BDI)  on  the  enemy  location  already  attacked  or 
currently  under  attack.  The  MAV  is  at  hand  and  is  launched  after  its  initialization 
sequence.  It  is  flown  either  manually  or  automatically  to  the  attack  sight  based  on  enemy 
location  information.  Once  in  the  general  vicinity  of  the  enemy  location,  the  MAV 
begins  an  observation  pattern  over  the  enemy  location  (either  manually  or  automatically 
controlled).  The  video  feedback  from  the  MAV  provides  BDI  from  which  the  operator 
may  determine  the  need  to  change  MAV  system  parameters  to  gain  more  use  BDI.  The 
video  feed  with  accompanying  geo-location  information  is  then  relayed  to  those  requiring 
the  information  to  possibly  complete  the  mission  or  plan  further  attack  of  the  enemy 
location. 

Throughout  the  flight  time  of  the  MAV,  the  video  feedback  should  be  such  that 
operating  personnel  can  positively  identify  the  enemy  and  major  objects,  cars,  buildings, 
large  weapons,  etc.  Once  sufficient  BDI  is  obtained  on  the  enemy  location  and/or  the 
MAV  has  reached  its  limits,  the  operator  can  either  return  the  MAV  to  the  base  or  choose 
to  continue  loitering  the  MAV  until  complete  power  failure  (i.e.  expend  the  MAV). 

4.1.3  Local  Area  Defense.  In  this  mission,  the  MAV  is  used  to  augment  the 
Local  Area  Defense  (LAD)  mission  by  providing  near  immediate  airborne  intelligence  to 
the  security  personnel.  The  set-up  for  the  mission  assumes  a  fortified  position  for  friendly 
forces  that  is  currently  guarded  by  traditional  security  forces.  The  position  may  be  near 
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populated  areas  and  it  may  also  be  near  terrain  and  vegetation  which  limits  the  line  of 
sight  capabilities  of  the  security  personnel. 

The  entry  condition  to  this  scenario  starts  with  a  ground  attack  launched  against 
a  friendly  location  or  base.  Determining  where  the  attack  is  launched  from  could  be 
accomplished  either  by  visible  reports  or  roughly  calculating  the  direction  of  enemy  fire. 
The  operator  then  uses  this  information  to  initialize  and  load  the  MAV  flight  parameters 
or  they  operate  the  MAV  manually  which  may  enable  a  quicker  launch.  The  operator 
then  deploys  the  MAV  and  monitors  the  video  stream  on  the  display  device.  While 
deployed,  the  operator  can  change  the  MAVs  route  by  changing  navigational  waypoints  or 
command  the  MAV  to  return  to  a  pre-defined  landing  zone.  Once  in  the  general  vicinity 
of  the  suspected  enemy  location,  the  video  feedback  from  the  MAV  allows  the  operator 
to  conduct  a  visual  search  for  the  enemy  or  threat  which  may  be  mobile  or  stationary, 
concealed  or  exposed.  The  MAV  operator  continues  to  track  the  enemy  position  until  the 
threat  is  eliminated,  the  MAV  has  expended  its  fuel,  or  the  MAV  is  beyond  its  transmitting 
range.  While  available,  the  video  feed,  with  accompanying  geo-location  information,  is 
then  used  by  the  appropriate  security  personnel  to  launch  an  attack  from  the  compound  or 
to  plan  a  later  attack  on  the  enemy’s  hiding  place. 

Throughout  the  flight  time  of  the  MAV,  the  video  feedback  should  be  such  that  the 
LAD  personnel  can  positively  identify  the  enemy.  Once  sufficient  information  has  been 
obtained  on  the  enemy  location  and/or  the  MAV  has  reached  its  limits,  the  operator  can 
either  return  the  MAV  to  the  base  or  choose  to  continue  loitering  the  MAV  until  complete 
power  failure  (i.e.  expend  the  MAV). 

4.2  MAV  Traceability 

The  purpose  of  traceability  in  design  is  to  ensure  that  the  system  being  designed  to 
fill  an  identified  capability  gap  can  be  traced  back  to  the  tasks  relevant  to  the  systems 
operational  concepts  and  scenarios.  Additionally,  traceability  is  an  integral  part  of 
the  Joint  Capabilities  Integration  and  Development  System  (JCIDS)  and  the  integrated 
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architectures  produced  to  answer  the  gap.  As  such,  the  capability  gap  initiates  the 
JCIDS  process  and  ensuing  traceability  analysis.  Two  primary  parts  of  the  JCIDS  process 
pertinent  to  this  thesis  were  the  creation  of  an  ISR  MAV  integrated  architecture  and  the 
performance  of  traceability  analysis  related  to  the  previously  discussed  mission  scenarios. 
However,  traceability  typically  occurs  before  a  solution  has  been  chosen  which  was  not  the 
case  for  this  effort  since  MAVs  were  identified  up  front  as  the  solution  to  the  tactical  ISR 
capability  gap.  Therefore,  a  quick  discussion  of  the  differences  between  current  UAVs  and 
MAVs  is  provided  which  is  followed  by  a  discussion  of  the  traceability  analysis  as  related 
to  the  Air  Force  Task  List  (AFTL)  and  special  operations  core  tasks. 

What  is  driving  all  of  the  development  effort  behind  MAVs?  They  surely  are  not 
more  capable  than  their  larger  brothers;  they  have  shorter  mission  endurance  and  they 
can  not  carry  the  quantity  or  the  quality  of  sensors  that  the  larger  aircraft  can.  The 
allure  of  MAVs  lies  in  their  small  operational  and  logistic  footprints  and  potential  for 
high  availability. 


A  quick  comparison  of  several  important  parameters  of  currently  operating  UAVs  is 
presented  in  Figure  4.1  provides.  The  larger  UAVs  such  as  the  Global  Hawk  and  Predator 
are  more  suited  to  long  endurance  missions  requiring  multiple  sensors.  These  are  mainly 


System  Description 

Endurance 

Payload 

Man-packable 

Availability 

Weight 

(empty  aircraft  only) 

Sensor 

Payload 

Global  Hawk  (RQ-4) 

42  hours 

Electro-optical  (EO) 

Synthetic  Aperature  Radar  (SAR) 
Moving  Target  Indicator 

Infrared  (IR) 

No 

Low 

25,600  lb 

2000  lb 

Predator  (RQ-1 ) 

24  hours 

Electro-optical  (EO) 

Synthetic  Aperature  Radar  (SAR) 
Infrared  (IR) 

No 

Low 

1,130  lb 

4501b 

Pointer  (FQM-151A) 

1-5  hours 

Electro-optical  (EO) 

Infrared  (IR) 

Yes 

2  x  501b  packs 

Medium 

101b 

21b 

MAV 

<  0.5  hours 

Electro-optical  (EO) 

Yes 

High 

<2  lb 

<  1  lb 

Figure  4.1  UAV  Specification  Comparison 


used  for  battlefield-level  surveillance  and  reconnaissance.  However,  these  have  a  very 
large  logistic  footprint  requiring  fixed  landing  fields  and  dedicated  operators  [6]  [5].  As 
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UAVs  get  smaller,  their  performance  and  endurance  capabilities  are  drastically  decreased 
when  compared  to  their  larger  brothers.  However,  the  advantage  is  that  these  smaller 
UAVs  are  carried  into  the  field  with  the  unit.  The  term  man-packable  is  pushed  to  its 
limits  with  the  Pointer  system  as  it  requires  a  vehicle  for  transportation  into  the  theater 
and  two  soldiers  carrying  50  lb  packs  when  the  unit  is  on  foot.  Availability  for  the  Pointer 
is  medium  since  their  usage  is  limited  to  specialized  units.  The  only  mini/micro  UAV  in 
the  group  is  the  generic  MAV.  It  performs  much  the  same  mission  as  the  Pointer;  however, 
it  sacrifices  mission  endurance  to  gain  extremely  small  size,  light  weight  and  affordability. 

All  of  the  previously  mentioned  systems  perform  an  ISR  mission  for  their  users.  The 
fact  that  different  users  have  different  requirements  gives  rise  to  a  UAV  family  of  systems. 
The  DoD  currently  has  the  capability  to  perform  battlefield  level  surveillance  with  the  two 
larger  platforms.  The  Pointer  system  was  a  start  at  miniaturizing  UAV  technologies  to 
allow  individual  units  to  perform  tactical  surveillance  and  reconnaissance.  However,  the 
large  size  of  the  system  and  the  extensive  set-up  and  tear-down  time  made  it  unsuitable  for 
quick  reaction  missions.  The  need  for  the  SOF  team  is  to  have  a  quick  reaction  system  to 
gather  tactical  surveillance  and  reconnaissance  within  an  operationally  significant  range 
that  does  not  require  the  team  to  give  up  other  mission  essential  equipment.  Therefore, 
MAVs  provide  a  viable  concept  that  can  feel  the  aforementioned  need. 

As  discussed  earlier,  traceability  begins  prior  to  selecting  the  concept  or  alternative 
to  answer  the  capability  gap.  Traceability,  as  shown  in  Figure  4.2,  ties  the  scenarios 
that  describe  the  capability  gap,  to  both  the  organizations  that  perform  the  missions 
and  the  applicable  tasks  as  defined  in  the  AFTL.  The  US  Special  Operations  Command 
(USSOCOM)  has  a  wide  range  of  mission  areas;  however,  two  core  tasks  (mission 
areas)  match  closely  with  the  three  missions  discussed  in  this  paper.  Counter-Terrorism 
addresses  both  the  MAV  reconnaissance  and  local  area  defense  missions.  Special 
reconnaissance  ties  into  the  previous  two  missions  and  adds  the  battle  damage  information 
mission.  Two  primary  tasks  and  several  specific  sub-tasks  were  selected  from  the  AFTL 
which  relate  to  the  three  mission  areas.  Once  this  portion  of  the  traceability  is  completed, 
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AFSOC  Mission 


Mission  Areas 

Combating 
Terrorism  Mission 

Special 

Reconnaissance 
(SR)  Mission 

Air  Force  Task 
List 

i 

AFT  6  -  Provide 

Information 

Agile  Combat 

Superiority 

Support 

AFT  3.1  -  Provide 
Information  Operations 
Capabilities 


AFT  3.1.1  -  Perform 
Information  Operations 
Functions 

I 

AFT  3.1. 1.1  -  Perform 
Information-in-Warfare 
Functions 


AFT  6.2  -  Provide  the 
Capability  to  Protect 


AFT  6.2.1  -  Protect 
the  Force 


AFT  6.2. 1.2-  Perform 
Force  Protection 


AFT  3.1. 1.1.1  - 

AFT  3/ 

.1.1.2- 

AFT  3.1. 1.1.3- 

Perform  Intelligence 

Perform 

Perform 

Activities 

Surve 

llance 

Reconnaissance 

Battle 

Damage 

Information 

Mission 


Over-the-Hill 
Reconnaissance  ^ 
Mission 


Local  Area 
Defense 
Mission 


Figure  4.2  Mission/Scenario  to  Air  Force  Task  Traceability 


some  of  the  (abreviated  list  of)  measures  provided  in  the  AFTL  and  shown  in  Table 
4.1  can  be  used  as  discriminators  to  determine  which  alternative  concept  best  fills  the 
gap.  Remember  that  MAVs  were  provided  as  the  solution  to  fill  the  gap  which  in 
essence  eliminated  the  need  to  perform  Functional  Area  Analysis  (FA A),  Functional 
Needs  Analysis  (FNA),  and  Functional  Solution  Analysis  (FSA)  as  well  as  an  Analysis 
of  Alternatives  (AoA). 

Following  the  selection  of  a  concept  (or  system)  to  fill  the  capability  gap,  an 
integrated  architecture  is  produced.  The  architecture,  along  with  the  mission  scenarios, 
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Table  4.1  AFTL  Measures  [40:103-104] 


Task 

Criterion 

Measure 

AFT  3. 1.1. 1.1  Perform 

Time 

To  conduct  adequate,  timely,  and  reliable 

Intelligence  Activities 

intelligence  activities  for  the  USAF  and 
other  agencies. 

Percent 

Of  accuracy  to  which  adversary  COGs  are 
identified  to  accomplish  predetermined 
objectives. 

Cost 

To  Perform  tactical  intelligence  activities. 

AFT  3. 1.1. 1.2  Perform 

Time 

To  systematically  observe  air,  or  surface 

Surveillance 

areas,  places,  persons,  or  things  by  visual, 
aural,  electronic,  photographic,  or  other 

means. 

Percent 

Of  accruacy  to  which  air  or  surface  areas, 
places,  persons,  or  things  can  be  observed 
by  visual,  aural,  electronic,  photographic, 
or  other  means. 

Cost 

To  perform  surveillance. 

AFT  3. 1.1. 1.3  Perform 

Time 

To  obtain,  by  visual  observation  or  other 

Reconnaissance 

detection  methods,  specific  information 
about  the  activities  and  resources  of  an 
adversary  or  potential  adversary. 

Percent 

Of  accuracy  to  which  specific  information 
about  the  activities  and  resources  of 
an  adversary  or  potential  adversary  is 
obtained. 

Cost 

To  perform  reconnaissance. 

is  then  be  used  to  develop  system  requirements.  Requirements  generated  from  the  initial 
ISR  MAV  architecture  will  allow  the  discipline  or  test  engineers  the  ability  to  define 
the  measures  needed  to  evaluate  system  performance  which  ultimately  ties  back  to  the 
ability  to  fill  the  capability  gap.  The  ISR  MAV  architecture  requirements  will  also  be 
classified  into  either  functional,  system,  or  derived  requirements.  Once  the  requirements 
are  established,  measures  of  effectiveness  (MOE)  relating  to  requirements  provide  a  means 
for  determining  the  operational  effectiveness  and  suitability  of  the  system.  These  top- 
level  measures  also  embody  characteristics  such  as  being  quantitative,  mission-oriented, 
and  testable  (objectively  or  subjectively).  Traceability,  for  the  purposes  of  this  project, 
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was  focused  on  creating  the  links  between  scenarios  and  tasks,  and  scenarios  and  the 
user  organizational  structure.  Additionally,  the  architecture  provides  the  groundwork  for 
identifying  and  refining  system  level  requirements  and  their  associated  MOEs. 

4. 3  Current  ISR  MAV  Architecture 

The  following  subsections  discuss  the  architectural  products  that  describe  an  ISR 
MAV  system  in  its  current  state.  Each  subsection  introduces  the  specific  product  and 
provides  its  respective  diagrams  and/or  descriptive  texts.  Areas  of  note  will  be  highlighted 
to  help  understand  each  view.  A  fully  expanded  version  of  each  product  and  their 
respective  integrated  dictionaries  may  be  found  in  the  appendices. 

4.3.1  AV-1  Over-view  and  Summary  Information.  This  architectural  product 
gives  the  top-level  information  required  to  understand  the  background,  purpose,  and  scope 
of  the  entire  architecture.  Since  it  is  text-based  and  relatively  short  in  length,  it  has  been 
included  here  in  its  entirety.  It  is  also  shown  in  Appendix  C. 

AV-1:  Overview  and  Summary  Information  for  ISR  MAV  (AS-IS) 

1.  Identification 

Name:  Intelligence,  Surveillance  and  Reconnaissance  Micro/Mini  Aerial  Vehicle  (AS-IS) 
Short  Name:  ISR  MAV  (AS-IS)  Architecture 
Involved  Organizations: 

AFRL/MN;  Munitions  Directorate 
AFRL/HE;  Human  Effectiveness  Directorate 

ASC/AAP;  Aeronautical  Enterprise  Program  Office,  System  Program  Office  (SPO) 
AFIT/ENY-GSE;  USAF  Graduate  Systems  Engineering  program;  architecture  developers. 
Date:  This  version  targets  the  FY05  timeframe.  The  period  for  the  development  of  this 
version  of  the  architecture  was  August  2004  to  March  2005. 

2.  Background:  Currently,  no  integrated  architecture  exists  to  define  the  use  of  the 
emerging  field  of  MAVs  within  the  Department  of  Defense  or  the  US  Air  Force.  MAVs 
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are  rapidly  emerging  as  a  productive  subset  of  the  larger  category  of  Unmanned  Aerial 
Vehicles  (UAV).  They  are  loosely  defined  as  being  small  enough  in  size  and  weight  to  be 
man-packable  for  use  in  austere  operational  environments  by  Special  Forces  personnel. 
The  MAV’s  size  and  ease  of  testability  allows  for  rapid  development  and  modification  of 
design  and  application. 

This  architecture  is  an  AS-IS  representation  of  a  generic  ISR-focused  MAV.  This 
baseline  architecture  is  used  to  understand  the  system,  track  changes  to  any  fielded 
systems,  and  to  determine  future  capability  shortfalls  that  should  be  addressed. 

3.  Purpose:  This  ISR  MAV  architecture  provides  a  baseline  for  the  current 
capabilities  of  operational  ISR  MAVs.  The  purpose  of  this  version  of  the  architecture 
(FY05)  is  detailed  in  Table  4.2  below. 

4.  Scope:  The  products  associated  with  this  architecture  depict  the  AS-IS  state 
of  a  generic  ISR  MAV  system.  This  architecture  includes  the  infrastructure  and  systems 
needed  to  operate  an  ISR  MAV  by  US  military  personnel. 

5.  Time  Frame:  The  architecture  depicts  the  weapon  system  in  its  current  state  and 
certain  evolutions  expected  to  be  implemented  through  FY05. 
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Table  4.2  Architecture  Purposes 


Architecture  Purpose 

Architecture  Product  Implications 

Describe  a  generic 
ISR  MAV  system  as  a 
baseline  to  fully  map 
the  necessary  interfaces 
needed  to  describe  the 
ISR  MAV  mission 

Architectural  elements  are  documented  that  are 
common  to  the  ISR  MAV  mission  and  can  be  used 
to  fully  understand  the  system’s  boundaries  and 
interfaces.  Specifically  the  OV-2,  OV-5,  and  SV-1 
depict  these  interfaces. 

Support  the 

development  of 

an  ISR  MAV  Full 
Scale  Production 

Contract  and  serve  as 
a  maintained,  authori¬ 
tative  decision  making 
tool  after  contract 
award 

Information  must  be  accurate  and  authoritative. 
Products  were  built  with  the  idea  in  mind  that  the 
future  changes  to  the  mission  profile  and  integrating 
advanced  technology  will  need  to  be  reflected  in  the 
baseline  architectures  prior  to  implementation 

Support  the  design 
of  tailored  ISR  MAV 
implementations 

The  generic  architecture  should  be  extensible  to 
reflect  C2  node  or  site  specific  variations  of  ISR 
MAVs  without  losing  linkage  and  consistency  with 
the  baseline  architecture  products 

Provide  traceability 

of  requirements 

to  architecture 

components 

To  be  meaningful,  the  granularity  of  the  architectural 
elements  should  be  small 

Support  the 

development  of  future 
test  plans 

OV-2,  OV-3,  SV-1  and  SV-6  will  aid  in  determining 
system  connectivity  and  interoperability  requirements 

Identify  modernization 
opportunities 

Certain  architecture  elements  are  candidates 
for  replacement,  re-engineering,  or  additional 
capabilities  as  discussed  in  the  accompanying  future 
capabilities  discussion 

Support  future 

acquisition  activities 
by  contributing  to  the 
refinement  of  ISR 
MAV  requirements 

helping  identify  areas 
for  modernization 

Requires  significant  granularity  across  a  variety  of 
OV  and  SV  products 

Be  an  integral  part  of 
the  larger  ISR  and/or 
UAV  architectures 

Use  of  same  or  interoperable  toolsets,  terminology, 
and  supporting  architecture  databases  where  available 
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4.3.2  AV-2  Integrated  Dictionaries.  While  the  Integrated  Dictionary  can  be 
represented  as  a  stand-alone  product,  describing  the  rest  of  the  architecture  in  only  text, 
here  it  is  broken  into  its  respective  products.  Each  product  presented  in  the  architecture  has 
an  accompanying  AV-2  following  it  to  describe  in  detail  each  of  the  objects,  connections, 
and  other  representation  of  each  product.  DoDAF  provides  a  basic  template  for  each 
product’s  AV-2  which  was  tailored  to  fit  the  scope  of  the  ISR  MAV  architecture.  At 
a  minimum,  every  representation  in  a  product  has  an  accompanying  description,  type, 
and  reference  to  which  other  views  include  it.  In  this  way,  many  basic  questions  in 
understanding  the  products  and  what  their  elements  represent  can  be  answered  by  referring 
to  the  respective  AV-2  in  the  appendix. 

4.3.3  OV-1  High-Level  Operational  Concept.  Creating  the  architectures  for 
each  of  the  previously  discussed  scenarios  begins  with  the  creation  of  the  high-level 
operational  concept  graphic  (OV-1)  and  its  associated  text  description.  The  over-the- 
hill  reconnaissance  and  battle  damage  information  (BDI)  missions  were  combined  due 
to  the  close  relationship  between  these  missions  and  are  shown  in  Figure  4.3.  To  perform 


Figure  4.3  OV-1  for  the  OTHISR  and  BDI  Scenario 
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BDI  with  the  MAV  system,  a  potential  target’s  location  must  be  known  and  be  within  the 
MAV’s  sensor  range.  The  two  MAV  nodes  shown  in  the  graphic  are  the  combat  controller 
(or  the  friendly  ground  unit  in  subsequent  views)  and  the  MAV  (or  aerial  vehicle).  External 
systems  consist  of  GPS  satellites,  the  air  operations  center  (AOC)  (or  headquarters  in 
subsequent  views),  and  strike  assets.  In  addition  to  providing  internal  and  external  nodes, 
the  graphic  provides  a  vision  of  node  connectivity  and  a  top-level  view  for  how  the  MAV 
system  operates. 

The  OV-1  for  the  LAD  scenario  (Figure  4.4)  looks  very  similar  to  the  over-the-hill 
reconnaissance  and  BDI  scenarios  with  the  exception  of  how  the  user  utilizes  the  MAV 
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Figure  4.4  OV-1  for  the  LAD  Scenario 

system.  All  three  scenarios  require  the  MAV  system  to  provide  information  which  can 
be  used  to  provide  better  situational  awareness  for  the  ground  unit  and/or  to  aid  in  the 
engagement  of  threats  and  ensuing  assessment  of  the  engagements.  However,  in  the  over- 
the-hill  reconnaissance  and  BDI  scenarios,  concealment  was  paramount  for  the  ground 


4-13 


unit.  In  the  LAD  scenario,  the  enemy  is  attacking  a  known  location  or  local  area  which 
drives  the  requirement  to  quickly  obtain  information  pertaining  to  the  threat. 


4.3.4  OV-2  Operational  Node  Connectivity.  The  OV-2  depicts  operational  nodes 
(internal  and  external)  and  needlines  in  order  to  show  a  need  to  exchange  information. 
Since  there  is  only  a  single  needline  between  two  nodes  it  can  contain  many  different 
types  and  formats  of  information.  The  Operational  Information  Exchange  Matrix  (OV- 
3)  presented  later,  breaks  apart  the  different  types  of  information  within  each  needline. 
An  OV-2  diagram  was  produced  for  each  of  the  three  operating  scenarios  and  these  three 
diagrams  were  then  compiled  into  a  Consolidated  OV-2  which  reflects  and  integrates  all 
of  the  scenarios. 

Over-the-Hill  Reconnaissance  OV-2:  The  first  OV-2  Figure,  4.5,  is  based  on  the 
over-the-hill  reconnaissance  scenario.  From  the  scenario,  two  internal  operational  nodes 
can  be  picked  out  based  on  relative  operational  function  or  activity.  The  Special  Ops  Unit 
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Figure  4.5  OV-2  for  the  Over-the-Hill  Reconnaissance  Scenario 
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node  comprises  all  operations  needing  to  be  performed  on  the  ground.  This  is  also  referred 
to  as  the  ground  aspect  of  the  system  and  includes  the  operator/user.  The  MAV  node, 
however,  is  referred  to  as  the  air  aspect  of  the  system  thus  containing  all  operations  needed 
to  be  done  while  in  flight.  These  two  nodes  need  to  be  able  to  communicate  so  the  operator 
can  control  the  airborne  node  as  well  as  retrieve  reconnaissance  data  from  it,  hence  the 
needline  Request/Commands,  Platform  and  Human  Interface.  Based  on  the  scenario,  there 
are  also  three  external  nodes.  The  first  external  node,  Headquarters ,  consists  of  the  Special 
Ops  Units  higher  headquarters  which  distributes  intelligence,  mission  tasks,  and  receives 
reconnaissance  information  once  gathered.  The  second  external  node,  Strike  Assets,  has 
the  option  to  either  receive  or  relay  last  known  enemy  positions  with  the  Special  Ops  Unit. 
By  receiving  the  enemy  positions  the  Strike  Assets  are  provided  the  information  needed 
to  strike  the  target.  In  contrast,  the  Strike  Assets  are  able  to  send  enemy  positions  to  the 
Special  Ops  Unit,  thereby  increasing  the  situational  awareness  of  the  unit  and  easing  their 
reconnaissance  operations.  The  third  external  node,  GPS  Satellites,  provides  the  MAV  with 
navigation  data  so  that  both  the  Special  Ops  Unit  and  MAV  know  where  it  is  located.  Note 
that  the  figure  helps  illustrate  these  information  exchanges  through  the  use  of  needlines. 

Battle  Damage  Information  OV-2:  Figure  4.6  is  based  on  the  battle  damage 
information  scenario.  From  the  scenario  similar  internal  and  external  operational  nodes 
and  needlines  can  be  picked  out  based  on  the  same  logic  as  in  the  Over-the-Hill 
Reconnaissance  OV-2.  Although  similar  to  the  preceding  scenario  it  is  important  to  see 
the  different  information  needs  (needlines)  required  by  two  of  the  three  external  nodes 
(there  was  no  change  with  the  GPS  Satellite  node).  The  Headquarters  node  consists  of 
the  Friendly  Ground  Units  higher  headquarters  which  places  a  request  for  battle  damage 
information  and  receives  the  information  once  it  has  been  collected.  The  other  change  was 
in  the  Strike  Assets  node  which  also  has  the  option  to  request  battle  damage  information, 
relay  strike  status  (when  scheduled  or  if  it  has  already  occurred),  and  receive  general 
feedback  on  the  information  gathered. 
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Figure  4.6  OV-2  for  the  Battle  Damage  Information  Scenario 


Local  Area  Defense  OV-2:  Figure  4.7  is  based  on  the  local  area  defense  scenario. 
Again,  from  this  scenario  similar  internal  and  external  operational  nodes  and  needlines 
were  picked  out  based  on  the  same  logic  as  in  the  preceding  two  scenarios.  Unlike  the 
previous  scenarios  the  need  for  Strike  Assets  was  not  identified.  The  only  other  distinct 
difference  is  that  the  previously  discussed  Headquarters  node  was  identified  as  Local 
Commander  /  Headquarters  which  consists  of  the  Friendly  Ground  Units  commanding 
officer  or  higher  headquarters  which  will  receive  enemy  ground  positions  once  collected. 

Scenario  Consolidation  OV-2:  The  consolidated  OV-2  takes  all  nodes  and 
needlines  from  the  three  scenarios  and  compiles  them  such  that  all  scenarios  map  to  a 
single  OV-2.  Figure  4.8  shows  the  result  of  the  consolidation.  Two  internal  nodes  represent 
the  ground  aspect  of  the  system  ( Friendly  Ground  Unit )  as  well  as  the  airborne  part  {MAV). 
A  total  of  three  external  nodes  are  identified  in  the  scenarios  and  are  reflected  in  this 
consolidation:  (. Headquarters ,  Strike  Assets ,  and  GPS  Satellites).  However,  one  external 
node  was  not  identified  in  the  scenarios  {Maintenance  Depot)  and  was  added  after  the  OV- 
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Figure  4.7  OV-2  for  the  Local  Area  Defense  Scenario 

5  operational  activity  model  identified  a  need  for  external  or  non-field  level  maintenance. 
This  new  node  handles  all  maintenance  that  can  not  be  performed  by  the  operator  in  the 
field. 

The  different  needlines  have  been  compiled  into  generally  named  needlines.  For 
example,  all  needlines  shown  between  the  Friendly  Ground  Unit  or  Special  Ops  Unit 
and  Strike  Assets  have  been  compiled  into  Communicate  with  Local  Strike  Assets.  With 
the  addition  of  the  Maintenance  Depot  external  node  a  new  needline  not  shown  in 
the  scenarios  was  drawn  to  the  Friendly  Ground  Unit.  This  needline,  labeled  System 
Maintenance  Needed/Requested,  covers  the  operator  requesting  maintenance  that  cannot 
be  performed  in  the  field  and  the  maintenance  personnel  acknowledging  when  the  system 
has  been  repaired. 

Throughout  the  rest  of  the  architecture  development  (from  here  forward)  all 
products  are  based  on  the  consolidated  mission  areas.  The  capability  of  the  MAV  in  three 
mission  areas  will  be  collectively  described  as  an  ISR  MAV. 
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Figure  4.8  Consolidated  OV-2  (reflecting  all  scenarios) 


4.3.5  OV-3  Operational  Information  Exchange  Matrix.  The  OV-3  Operational 
Information  Exchange  Matrix  aids  in  the  integration  and  definition  of  information 
exchanges  throughout  all  operational  view  products.  Essentially,  it  identifies  who  is 
involved,  why  the  information  is  necessary,  and  how  it  is  exchanged.  Another  way  to 
look  at  this  product  is  that  it  takes  information  elements,  needlines,  nodes,  activities,  and 
events  from  other  operational  views  as  well  as  their  corresponding  AV-2  dictionaries  and 
correlates  them  into  a  matrix.  Due  to  this  integration  there  is  no  need  for  an  AV-2  to  be 
produced  for  this  view  for  it  would  be  redundant  to  the  matrix. 

As  mentioned  in  Section  3.2.3,  the  OV-3  matrix,  as  with  any  defined  matrix,  is 
a  set  of  rows  and  columns  where  their  intersections  contain  information.  The  rows 
contain  all  information  contained  within  a  particular  information  exchange.  The  columns 
show  specific  information  based  on  the  columns  heading.  Due  to  the  scope  and  goal 
of  this  research  only  certain  columns  will  contain  data;  those  shaded  columns  (i.e.  blank 
columns)  have  been  left  for  anyone  who  wishes  to  expand  on  this  research  (i.e.  if  applied  to 
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a  specific  application).  For  particular  information  regarding  the  rows  or  column  headings 
and  their  contents,  refer  to  the  OV-3  matrix  figures  located  within  Appendix  F  (total  of  5 
figures). 

4.3.6  OV-4  Organization  Relationships  Chart.  This  product  illustrates  the 
command  structure  or  relationships  among  human  roles,  organizations,  or  organization 
types  that  are  the  key  players  in  an  architecture  [24:4-27].  Figure  4.9  represents  the  ideal 
steady-state  use  and  interaction  of  the  organizations  required  to  produce  an  ISR  MAV 
capability.  This  is  how  a  generic  ISR  MAV  organizational  relationship  could  look. 


Development  Team 

Figure  4.9  OV-4  Organizational  Relationships  Chart 

Many  influences  come  to  bear  on  how  organizations  actually  are  formed  and  work: 
existing  organizational  structure,  politics,  command  influence,  applications  of  various 
organizational  theory,  etc.  This  OV-4  was  designed  on  an  ideal  concept  of  functional 
organizations  and  their  logical  interaction  with  one  another  in  an  acquisitions  and  logistics 
environment.  In  cases  of  rapid  spiral  development,  working  groups  and  contingency 
operations,  this  ideal  could  be  changed  dramatically. 
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The  ISR  MAV  OV-4  shows  the  three  main  communities  that  interact  -  the 
developers,  the  sustainers  and  the  operators.  These  are  shown  as  the  MAV  Lab,  the  MAV 
System  Program  Office  (SPO),  and  the  branches  of  the  Special  Operations  community 
respectively. 

Other  than  the  two  main  commands  (AF  Materiel  Command  and  AF  Special 
Operations  Command),  the  rest  of  the  organizations  and  human  roles  are  generically 
represented  (or  named).  This  was  done  to  allow  the  architecture  to  be  extensible;  able 
to  be  tailored  to  specific  purposes  of  the  generic  ISR  MAV. 

The  MAV  Lab  is  responsible  for  transitioning  the  technology  to  the  MAV  SPO  and, 
in  return,  the  MAV  SPO  provides  feedback  and  direction  towards  future  spiral  designs 
of  the  MAV.  The  MAV  SPO  is  then  responsible  to  the  operator  community  to  sustain  the 
MAVs,  and  in  return  the  operators  will  provide  feedback  to  the  SPO  on  issues  they  are 
having  with  the  current  MAV  as  well  as  relay  capability  requirements. 

The  MAV  Lab  and  the  MAV  SPO  have  similar  setups  due  to  the  fact  that  many 
of  the  same  technical  and  program  related  functions  must  occur  in  both  development 
and  sustainment.  In  development,  the  organizations  are  dedicated  to  integration,  test  and 
research.  However,  in  the  SPO  where  the  system  is  relatively  stable,  an  organization  for 
logistics  management  is  needed.  It  is  likely,  though  not  required,  that  contractor  support 
provided  for  the  development  of  the  ISR  MAV  plays  an  important  role  in  the  production 
contracts  as  well. 

In  this  construct  of  the  steady  state  MAV  organization,  the  Special  Forces  teams 
may  not  interface  directly  with  the  SPO  for  support.  They  will  work  through  their  mission 
support  function  within  their  command,  who  would  then  work  with  the  SPO  on  and 
technical/support  issues. 

4.3.7  OV-5  Operational  Activity  Model.  The  Operational  Activity  Model  (OV- 
5)  is  a  functional  decomposition  of  the  system  tasks  consisting  of  inputs,  controls,  outputs 
and  mechanisms  (ICOM).  Figure  4.10  is  the  A  minus  One ,  or  external  systems  diagram 
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which  sets  the  stage  for  how  the  system  interacts  with  its  environment  as  well  as  where 


Fused  Target  Information 


Figure  4. 10  OV-5  External  Systems  Diagram 

the  system  receives  and  sends  information.  The  primary  function  of  the  system  is  to 
Provide  ISR  Capabilities  as  shown  in  box  AO.  The  system  requires  a  Tasking  from  either 
headquarters/local  commander  or  a  strike  asset.  To  accomplish  this  mission,  the  system 
requires  Operational  MAVs  from  the  maintenance  depot  and  the  Navigation  Data  provided 
by  the  GPS  satellites.  Using  these  elements,  the  system  performs  its  mission  and  provides 
Fused  Target  Information  as  an  output  to  the  command  and  control  infrastructure  or  the 
local  strike  assets.  The  last  line  is  Repairs  Required.  External  system  repairs  are  necessary 
only  if  something  inside  the  system  boundary  cannot  be  repaired  in  the  field. 

Next  in  the  decomposition  (Figure  4.11)  is  the  A  minus  Zero  or  context  diagram. 
This  shows  all  inputs,  outputs,  controls  and  mechanisms  (ICOM)  for  the  system.  The 
system  inputs  and  outputs  were  discussed  previously,  but  we  have  new  information 
regarding  the  mechanisms  and  controls  for  the  system.  Flight  rules  or  Airspace 
Deconfliction  consists  of  any  external  influences  such  as  weather,  local  radio  traffic, 
proximity  to  other  operating  units,  etc  that  have  an  influence  on  how  or  when  the  MAV  is 
used.  Mission  Operating  Procedures  are  any  other  limitations  or  guidelines  imposed  by 
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Figure  4.11  OV-5  Context  Diagram 


the  particular  mission  type.  As  for  the  mechanisms,  the  MAV  system  requires  operational 
MAVs,  the  ground  station  and  the  human  operator.  The  parenthesis  around  the  head  of  the 
arrow  in  the  diagram  represents  that  this  line  is  going  to  be  tunneled  and  will  not  appear 
in  subsequent  decompositions. 

The  primary  system  decomposition,  shown  in  Figure  4.12,  is  the  first  diagram 
breaking  down  the  particular  aspects  of  how  the  system  will  do  its  job.  Shown  here 
are  the  inputs  and  outputs  previously  discussed,  as  well  as  the  five  primary  functions  of 
the  MAV  system:  Provides  Information  Processing,  Enable  Launch  MAV,  Provides  ISR 
MAV  Platform,  Enable  Launch/Recover  MAV  and  Provide  Field  Level  Maintenance.  The 
decompositions  for  these  components  follow  the  AO  diagram.  Full  descriptions  for  each 
data  block  and  flow  line  can  be  found  in  the  AV2  Integrated  Dictionary  for  the  OV5  in 
Appendix  H. 


4-22 


Figure  4.12  OV-5  Level  AO 


4.3.8  OV-6C  Operational  Event  Trace  Description.  This  architectural  product 
shows  a  time-ordered  view  of  the  actions  occurring  within  the  operational  nodes  of  the 
system  based  on  a  given  scenario.  This  scenario  serves  as  the  operational  event  trace 
description  and  guides  the  development  of  the  operational  event  trace  diagram. 

Operational  Scenario  (Operational  Event  Trace  Description)  The  entry 
condition  to  this  consolidated  scenario,  shown  in  Figure  4.13,  starts  with  a  mission 
being  directed  or  already  in  progress  [mission  directed,  1.1].  A  friendly  team  member 
decides  to  utilize  the  MAV  system  to  obtain  ISR  info  (decision  to  launch,  1.2).  The 
MAV  is  at  hand  and  is  launched  after  its  prep  time  (system  initialized,  1.5,  GPS  synch 
implied,  1.4,  1.3,  MAV  ready  for  launch,  1.6,  launch  MAV,  1.7).  The  MAV  performs  the 
mission  programmed  into  it  during  system  initialization  (perform  mission  profile,  1.9). 
The  operator  can  also  update  the  mission  profile  or  fly  it  manually  (update  mission  profile, 
1.8).  The  operator  observes  the  sensor  feedback  from  the  MAV  and  reacts  accordingly 
(collect  sensor  info,  1.12,  transmit  sensor  info,  1.16,  receive  sensor  info,  1.11,  process 
info,  1.14,  additional  mission  profile  updates,  1.8).  If  required  or  necessary,  the  collected 


4-23 


ISR  info  from  the  MAY  may  be  relayed  to  a  local  commander/headquarters  or  to  strike 


Figure  4.13  OV-6c  Operational  Event  Trace  Description 


assets  (transmit  ISR  info,  1.17,  receive  ISR  info,  1.18,  1.19).  The  decision  to  relay  this 
information  is  left  to  the  operator.  Once  sufficient  ISR  information  is  obtained  or  the 
MAV  has  reached  its  limits,  the  operator  can  either  return  the  MAV  to  the  base  (direct  land 
sequence,  1.10,  perform  land  sequence,  1.13,  recover  MAV,  1.15)  or  choose  to  continue 
loitering  the  MAV  until  complete  power  failure;  expending  the  MAV. 

Using  this  scenario,  all  units  of  behavior  (or  actions)  were  assigned  to  the 
responsible  operational  nodes  (or  swimlanes)  and  sequencing  was  added  to  the  diagram. 
The  references  to  these  actions  were  then  added  back  into  the  operational  event  trace 
description.  This  way  the  diagram  and  description  are  linked  and  can  be  used  together  to 
fully  represent  the  scenario. 

The  flow  through  the  operational  event  trace  diagram  is  relatively  straight  forward. 
The  one  alternate  path  junction,  seen  in  the  middle  of  the  diagram,  represents  the  ability 
to  command  the  MAV  with  either  new  mission  profiles,  to  land,  or  allow  it  to  perform  its 


4-24 


mission  as  previously  programmed.  It  should  be  noted  that  this  diagram  is  only  a  time- 
ordered  representation  of  the  scenario.  It  only  shows  what  actions  are  temporally  linked 
and  dependent  upon  each  other. 


4.3.9  OV-7  Logical  Data  Model.  The  logical  data  model  defines  the  data 
domain  for  a  given  architecture.  Instrumental  in  creating  this  model  is  having  access 
to  a  completed  operational  activity  model.  The  ICOMs  from  the  OV-5  are  commonly  used 
to  define  data  entities  or  are  attributes  within  another  data  entity. 


The  MAV  system  data  model  shown  in  Figure  4.14  revolves  around  sensor 
information,  telemetry  information,  and  commands.  Additionally,  the  system  requires 
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Figure  4.14  OV-7  Logical  Data  Model 


GPS  satellite  lock  during  all  portions  of  the  flight  profile  for  normal  operation,  however,  in 
the  case  that  GPS  becomes  or  is  not  available  the  system  can  be  manually  guided  through 
the  User  Commands  entity.  A  status  entity  is  used  to  capture  the  various  faults  that  may 


occur  while  using  the  MAV  system. 
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Before  issuing  commands  to  the  air  vehicle,  a  Tasking  must  exist,  and  the  system 
status  must  be  fault  free.  During  system  use,  the  status  is  continually  updated  to  provide 
the  operator  indications  of  possible  problems.  Information  sent  from  the  air  vehicle  is 
comprised  of  raw  sensor  package  data  and  raw  flight  telemetry  data.  These  two  distinct 
pieces  are  connected  to  their  parent  entity  known  as  Raw  Data  which  in  turn  feeds  into  the 
Fused  Target  Information  entity  to  produce  ISR  information. 

The  view  provided  by  this  Logical  Data  Model  is  somewhat  abstract  allowing  the 
disciplined  engineers  the  flexibility  to  tailor  the  entities,  either  by  adding,  subtracting  or 
altering  the  keys,  attributes,  or  relationships  contained  within  the  data  model. 

4.3.10  SV-1  Systems  Interface  Description.  This  product  depicts  system  nodes, 
the  systems  residing  in  those  system  nodes,  and  the  functions  performed  by  those  residing 
systems.  Also  identified  here  are  the  interfaces  between  systems. 

In  order  to  show  the  proper  amount  of  detail  for  an  initial  baseline  architecture,  this 
research  concentrates  on  the  two  more  detailed  versions  of  the  possible  four  SV-1  versions 
identified  in  section  3.2.3.  The  versions  completed  were  the  SV-lb;  mternodal  depiction 
of  system-to-system  interfaces,  and  the  SV-lc;  intranodal  depiction  of  system-to-system 
interfaces.  Both  the  SV-lb  and  the  SV-lc  views  include  the  functions  performed  by  each 
system  (with  the  exception  of  external  systems).  The  remainder  of  this  section  presents 
these  diagrams  and  their  supporting  textual  descriptions. 

Creation  of  the  SV-lb  started  with  the  consolidated  OV-2  operational  node  connec¬ 
tivity  diagram  (Figure  4.8),  where  operational  nodes  became  system  nodes  (shaded  circles) 
and  external  nodes  became  external  systems  (shaded  rectangles  outside  of  the  nodes). 
The  OV-2  diagram  establishes  the  need  to  communicate  between  nodes,  otherwise  known 
as  needlines.  These  needlines  are  used  to  establish  one  or  more  system  interfaces  in 
the  SV-lb  which  are  depicted  as  internal  interfaces  (solid  lines)  or  external  interfaces 
(dashed  lines).  For  example,  the  Platform  Communication  needline  becomes  Platform 
Interface  and  Request/Commands,  ISR  Data  interfaces.  Interfaces  within  the  SV-lb 
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Figure  4. 15  SV-lb  System-System  Interfaces 


also  correspond  to  the  needline  definitions  in  the  OV-2,  however,  note  that  the  Platform 
Communication  needline  was  separated  into  two  interfaces.  The  Platform  Interface 
involves  any  direct  contact  between  the  Human  Operator  and  Air  Vehicle  systems  while 
the  Request/Commands,  ISR  Data  interface  includes  any  communication  between  the  two 
system  nodes. 

The  remaining  two  diagrams  are  the  intranodal  versions  shown  in  Figures  4.16  and 
4.17  for  both  the  Friendly  Ground  Unit  and  MAV  system  nodes.  Although  the  diagrams 
are  similar  to  the  SV-lb,  the  SV-lc  shows  the  interfaces  within  the  system  nodes.  Since 
each  interface  is  defined  in  the  AV-2  dictionary  and  its  purpose  is  hinted  at  in  the  diagrams 
above,  they  will  not  be  described  here.  The  only  clarification  that  will  need  to  be  made  is 
that  of  the  power  situation  in  both  system  nodes. 

Notice  in  the  MAV  system  node  (Figure  4.17)  that  power  is  depicted  as  an  interface; 
however,  in  the  Friendly  Ground  Unit  node  (Figure  4.16)  it  is  not.  This  is  due  to  the 
power  (and  weight)  limitations  imposed  by  the  Air  Vehicle  system.  To  ensure  that  the 
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Figure  4.16  SV-lc  Intranodal  Version  of  the  Friendly  Ground  Unit 


Air  Vehicle  can  provide  flight  all  systems  within  the  MAV  node  need  to  utilize  the  power 
already  provided.  If  the  Air  Vehicle  cannot  provide  the  power  needed  then  the  system 
will  either  be  required  to  find  some  means  to  require  less  power  or  sacrifice  some  of  its 
weight  allocation  in  order  to  have  an  internal  power  supply.  Ideally  both  the  Payload 
or  Sensor  Package  and  MAV  Airborne  Communication  System  would  use  the  provided 
power  supply  such  that  design  (or  functional)  tradeoffs  would  not  have  to  be  made  (i.e. 
the  power  supply  would  take  up  weight  allocation  normally  allocated  by  functions).  Of 
course  if  these  system  resident  to  the  MAV  node  do  not  require  power  provided  by  the  Air 
Vehicle  then  this  link  would  not  exists.  This  problem  is  not  addressed  within  the  Friendly 
Ground  Unit  because  the  weight  limitations  are  a  little  more  relaxed  and  current  hardware 
systems  being  used  already  come  with  their  own  power  source.  Power  will  only  appear  if 
the  systems  within  the  Friendly  Ground  Unit  are  decomposed  into  subsystems. 

Based  on  Figure  4.16,  a  total  of  five  systems  exist  within  the  Friendly  Ground 
Unit  system  node  and  are  depicted  as  non-shaded  rectangles:  field  communication 
system,  human-computer  interface  (HCI),  Human  Operator,  MAV  Ground  Communi- 
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Figure  4.17  SV-lc  Intranodal  Version  of  the  MAY 


cation  System,  and  Signal/Data  Processor.  Each  system  includes  a  set  of  functions,  where 
the  system  functions  define  what  the  system  is  responsible  for.  These  system  functions  are 
located  to  the  right  of  the  system  name  in  a  smaller,  italicized  font. 

The  field  communication  system  allows  the  Human  Operator  to  communicate 
gathered  ISR  information  and  mission  directives  with  higher  Headquarters  or  Strike 
Assets.  Examples  of  such  systems  include  satellite  communication  radios  or  a  general 
purpose  field  radio.  The  Human-Computer  Interface  includes  those  items  that  give 
feedback  (display,  speakers)  to  the  Human  Operator  as  well  as  those  that  allow  users 
to  supply  input  to  the  system  (keyboard,  mouse,  touch  screen,  microphone).  The  Human 
Operator  is  a  model  of  the  operator’s  role  in  the  system.  The  operator  either  affects  the 
system  through  direct  contact  {Platform  Interface  and  Field  Communication  Interface), 
through  the  HCI  system  (User  Feedback  and  Inputs  Interface),  or  through  the  request  of 
outside  maintenance  to  the  Maintenance  Depot  system.  The  MAV  Ground  Communication 
System  allows  all  systems  within  the  friendly  ground  unit  to  communicate  directives  with 
the  airborne  systems  in  the  MAV  by  ensuring  that  data  can  be  sent  to  and  received  from  the 
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MAV  Airborne  Communication  System.  Examples  of  such  hardware  equipment  include 
transmitters,  receivers  and  antennas.  The  Signal/Data  Processor  system  processes, 
converts,  and  manipulates  data  such  that  the  proper  data  packets  can  be  delivered  to  the 
HCI  and  the  MAV  Ground  Communication  System. 

The  MAV  system  node,  shown  in  Figure  4.17,  contains  three  systems  that  enable  the 
collection  and  transmission  of  ISR  data.  These  systems  are  also  depicted  with  non-shaded 
rectangles  within  the  system  node  and  the  system  functions  are  to  the  right  of  the  system 
name. 

The  Air  Vehicle  allows  other  systems  within  the  MAV  to  operate  as  airborne 
systems.  Examples  of  hardware  systems  that  could  perform  the  system  functions  are 
an  aircraft  fuselage  with  wings,  autopilot,  and  propulsion  system.  The  MAV  Airborne 
Communication  System  allows  airborne  systems  within  the  MAV  to  communicate  gathered 
data,  directives,  and  status  information  with  the  ground  systems  Friendly  Ground  Unit 
by  ensuring  that  data  can  be  sent  to  and  received  from  the  MAV  Ground  Communi¬ 
cation  System.  Examples  of  such  hardware  equipment  include  transmitters,  receivers  and 
antennas.  The  purpose  of  the  Payload  or  Sensor  Package  system  is  to  collect  and  provide 
the  needed  ISR  information  by  utilizing  the  power  source  supplied  by  the  Air  Vehicle 
system.  Once  the  ISR  information  is  obtained,  it  is  sent  to  the  MAV  Airborne  Communi¬ 
cation  System  for  transmission. 

4.3.11  SV-4  Systems  Functionality  Description.  The  SV-4  shows  the  functional 
hierarchies  and  system  functions  of  the  ISR  MAV.  Similar  to  the  OV-5,  this  product 
decomposes  the  top-level  functions  and  shows  their  relationships  and  data  exchanges. 
This  product  takes  the  functions  listed  in  the  systems  of  the  SV-1  and  shows  their  inter¬ 
relationships.  The  data  exchanges  are  more  detailed  and  are  described  fully  in  the  SV-6. 
While  the  OV-5  looked  at  all  operational  activities  of  the  system,  the  SV-4  is  a  data-focused 
product;  hence  the  activity  of  non-field  level  maintenance  was  not  included. 
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The  system  functional  decomposition  is  shown  in  Figure  4. 18.  The  primary  function 
of  Providing  ISR  Capabilities  is  at  the  top  and  is  sub-divided  into  its  subsystem  functions 


Figure  4.18  SV-4  Functional  Decomposition 


Perform  Ground  Unit  Functions  and  Perform  MAV  Functions.  From  here,  the  functions 
continue  to  be  decomposed  until  they  reach  a  level  that  could  be  assigned  to  component- 
level  design.  The  following  views  will  show  more  of  the  interaction  between  the  sub 
functions. 

Figure  4.19  shows  the  top-level  interaction  of  the  functions  of  the  system.  At  this 
level  of  detail,  the  functions,  external  systems  and  data  exchanges  look  very  similar  to 
products  in  the  operational  view.  That  is  because  at  this  level,  all  of  the  major  nodes 
and  interactions  are  the  same.  The  true  benefits  of  this  product  come  at  the  lower  levels 
of  decomposition  where  specific  data  exchanges  and  subfunctions  begin  to  the  form  the 
physical  system. 

The  0-Level  Diagram  is  decomposed  further  into  levels  1  and  2.  Level  1  shows  the 
break-out  of  the  first  major  sub-function,  Perform  Ground  Unit  Functions.  At  this  level, 
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Figure  4.19  SV-4,  0- Level  Diagram 


many  of  the  functions  and  interactions  are  similar  to  the  SV-lc.  Level  2  provides  the 
break-out  of  the  second  major  sub-function,  Perform  MAV  Functions.  The  complete  set  of 
functional  decomposition  diagrams  are  found  in  Appendix  K.  In  each  diagram,  one  will 
see  how  the  sub-functions  interact  and  the  data  exchanges  are  assigned. 
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4.3.12  SV-5  Operational  Activity  to  Systems  Function  Traceability  Matrix.  The 
SV-5  (Figure  4.20  and  4.21)demonstrates  the  relationship  between  operational  activities 
and  system  functions  to  ensure  the  architecture  has  traceability  (reference  Section  3.2.3). 
The  relationship  is  rated  on  support  status  of  the  functionality  and  whether  or  not  the 
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system  is  fielded.  The  degree  to  which  a  system  supports  the  functionality  is  defined  by 
the  numerical  status  code.  These  status  codes  are  numbered  one  to  three  and  where  there 
is  no  code,  a  relationship  does  not  exist  or  is  not  planned.  A  status  code  of  one  implies  full 
functionality  is  provided  and  the  system  is  fielded.  A  status  of  two  means  the  function  is 
partially  provided  or  fully  provided  but  the  system  has  not  yet  been  fielded.  A  status  code 


4-33 


of  three  means  functionality  is  planned  but  not  developed.  Status  codes  were  not  produced 
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in  this  research  since  this  is  a  baseline  architecture  intended  for  generic  application; 
however,  the  relationships  between  the  operational  activities  and  system  functions  are 
identified.  The  SV-5  matrices  show  systems  and  their  system  functions  related  to  the 
operational  activities  within  a  capability  and  then  to  the  mission  capability  (in  this  case  the 
capability  to  perform  reconnaissance,  battle  damage  information,  and  local  area  defense 
was  used).  When  this  matrix  is  applied  to  a  particular  application,  the  status  codes  can 
be  filled  in.  This  identifies  stovepiped  systems,  redundant/duplicate  systems,  gaps  in 
capability,  and  possible  future  investment  strategies  [24]. 

The  systems  and  system  functions  used  in  the  SV-5  matrix  are  pulled  from  the  SV- 
1  systems  interface  description  diagrams  while  the  operational  activities  and  capabilities 
are  from  the  OV-5  operational  activity  model.  Not  all  operational  activities  are  used, 
only  those  lowest  level  activities  are  included  because,  if  the  low  level  activity  relates 
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to  a  system  function,  then  so  does  its  parent.  Essentially,  the  capabilities  are  the  first 
level  activities  shown  in  the  OV-5.  This  helps  to  break  down  the  mission  capability  while 
grouping  the  activities.  Both  Figures  4.20  and  4.21  are  of  the  SV-5  traceability  matrices 
produced  for  the  baseline  architecture. 

4.3.13  SV-6  Systems  Data  Exchange  Matrix.  The  SV-6  Systems  Data  Exchange 
Matrix  aids  in  the  integration  and  definition  of  system  interfaces  throughout  all  system 
views.  It  defines  and  integrates  the  system  functions  involved,  data  containing  elements, 
and  how  data  on  the  interface  is  exchanged.  Normally,  this  architectural  product  contains 
only  automated  interfaces,  meaning  those  interfaces  that  represent  machine  interaction. 
Most  of  the  interfaces  within  the  system  views  of  this  research  follow  this  principle; 
however,  there  are  four  that  are  considered  non-automated.  These  non-automated  links  are 
included  because  this  is  an  initial  baseline  architecture  where  clarity  is  essential.  These 
non-automated  interfaces  all  connect  to  the  Human  Operator  system  and  are:  Platform 
Interface,  Field  Comm  Interface,  User  Feedback  and  Inputs,  and  Maintenance  Required. 

Just  as  in  the  OV-3  operational  information  exchange  matrix,  the  SV-6  is  a  matrix 
with  a  set  of  rows  and  columns  where  their  intersections  contain  interface  information. 
The  rows  contain  all  information  contained  within  a  particular  interface  exchange.  Since 
the  relationship  between  system  interfaces  and  system  data  exchanges  are  one-to-many 
they  are  categorized  first  by  the  system  interface  name  shown  in  all  versions  of  the  SV- 
1  and  then  by  the  system  data  exchange  name  which  can  be  SV-6  unique  but,  in  this 
case,  correlates  to  the  OV-3’s  information  exchange  names.  The  columns  show  specific 
information  based  on  the  column  heading.  Due  to  the  scope  and  goal  of  this  research 
only  certain  columns  contain  data;  those  shaded  columns  are  left  blank  for  anyone  who 
wishes  to  expand  on  this  research  (i.e.  if  applied  to  a  specific  application).  For  particular 
information  regarding  the  rows  or  column  headings  and  their  contents,  refer  to  the  SV-6 
matrix  figures  located  within  Appendix  N  (total  of  7  figures). 
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4.4  DOTMLPF  Considerations 


All  of  the  architectural  views  presented  previously  refer  to  the  operation  of  a 
material  system.  Other  areas  of  the  ISR  MAV  system’s  operation  need  consideration 
as  well.  In  the  Joint  Capabilities  Integration  and  Development  System  (JCIDS),  much 
emphasis  is  given  to  addressing  capability  impacts  in  the  areas  of  doctrine,  organization, 
training,  materiel,  leadership  and  education,  personnel,  and  facilities  (DOTMLPF).  These 
areas  are  considered  to  be  outside  of  the  systems  physical  boundaries;  however,  they  play 
a  crucial  role  in  the  actual  capability  achieved.  As  this  system  architecture  is  already  a 
materiel  solution  to  the  capability  gap  identified  in  Chapter  II,  this  DOTMLPF  discussion 
will  omit  the  material  discussion  and  assumes  it  as  a  given. 

4.4.1  Doctrine.  The  ISR  MAV  may  have  a  long  term  impact  on  the  doctrine  of 
the  ISR  community;  however,  in  the  near  future,  the  ISR  MAV  represents  another  tool  for 
the  special  operations  forces.  The  SOF  teams  will  still  be  employed  and  be  assigned  to 
missions  in  the  same  manner  in  which  they  normally  are,  but  the  ISR  MAV  is  a  new  tool 
that  will  enhance  their  mission  effectiveness.  Since  there  is  no  fundamental  change  to  the 
user’s  core  tasks,  the  ISR  MAV  is  not  likely  to  affect  doctrine  in  the  near  future. 

4.4.2  Organization.  Organizational  impacts  may  occur  in  two  different  levels: 
tactical  and  developmental/sustainment.  The  changes  to  the  tactical  level  would  be  the 
decision  to  make  the  ISR  a  dedicated  position  on  the  deploying  teams,  or  have  every 
member  become  ISR  MAV  capable.  This  could  lead  to  ISR  MAV  specialization  within 
teams.  Then  future  variants  of  the  MAV  would  fall  that  member,  however  the  use  of  the 
MAV  would  be  person  dependant.  If  every  member  of  the  team  is  ISR  MAV  capable 
(trained  and  equipped)  then  its  use  would  become  more  available.  This  method  would 
require  more  assets  and  likely  more  repairs  due  to  storage  and  transport,  but  it  would 
make  the  capability  more  available  when  needed. 

The  other  organizational  change  would  require  the  formation  of  (if  one  is  not  already 
present)  and  development  of  relationships  between  a  development  organization  and  a 
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sustainment  organization  to  handle  the  ISR  MAV.  Architectural  view  OV-4  shows  a  likely 
steady-state  view  of  such  organizational  relationships. 

4.4.3  Training.  Training  on  the  ISR  MAV  system  is  necessary  in  order 
to  operate  it  successfully.  While  many  varieties  of  training  delivery  can  be  imagined 
(classroom,  field,  virtual,  verbal,  written,  on-job-training  (OJT),  etc.)  the  top-level  original 
requirement  of  operable  by  trained  personnel  remains. 

There  are  essentially  two  major  systems  that  an  operator  must  become  trained  on 
and  familiar  with  to  operate  the  system:  the  ground  station,  and  the  MAV.  The  MAV 
is  a  largely  electro-mechanical  system  and  so  the  operate  would  need  to  be  trained  in 
initialization  (power  on)  of  the  MAV,  launch  procedures,  minor  parts-replacement  repairs, 
recovery  of  the  MAV  and  storage/transport  of  the  MAV.  The  ground  station  is  largely 
a  hardware/software  unit  and  so  the  operator  would  need  to  be  trained  in  initialization 
of  the  system  and  software  program,  software  navigation,  basic/intermediary/advanced 
operation  of  the  system  through  the  software  program,  and  storage/transport  of  the  system. 
Both  systems,  as  a  collective,  would  require  a  user  to  have  a  basic  level  of  training  that 
would  enable  them  to  initialize  the  system,  program  a  simple  flight  plan,  launch  and 
recover  the  system,  and  simple  manipulation  of  the  data.  An  intermediate  level  of  training 
would  include  operations  such  as  advanced  flight  planning,  manual  flight  control,  and 
advanced  data  manipulation.  The  advanced  level  of  training  would  allow  the  operator 
to  manipulate  limits  on  system  parameters  such  as  air  speed,  bank  angles,  and  manual 
commands  in  order  to  perform  complicated  flight  patterns. 

A  classroom  or  virtual  environment  could  hand  an  introduction  of  the  system  and 
most  of  the  software  operation.  Through  use  of  a  training  software  program,  the  trainee 
could  virtually  fly  an  MAV  through  the  required  training  flight  programs  for  certification. 
However,  due  to  the  flight  aspects  of  the  system,  a  field  or  OJT  training  environment  would 
be  preferable.  In  this  method  of  delivery,  the  trainee  will  have  instant  feedback  of  their 
operating  skills.  In  the  field  or  on  a  range,  the  trainee  could  also  simultaneously  be  trained 
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on  MAV  launch,  recovery,  storage  and  transport  of  the  system,  and  all  the  other  aspects  of 
the  system  that  make  it  unique. 

4.4.4  Leadership  and  Education.  Leadership  and  education  would  be  impacted 
in  the  long  term  for  the  ISR  MAV.  The  system  would  now  enable  Special  Forces  to  have 
a  larger  local  area  situational  awareness.  Leaders  would  need  to  realize  this  and  it  may 
affect  how  they  employ  the  teams  that  have  the  ISR  MAV  verses  those  that  do  not.  The 
ISR  MAV  capability  will  influence  the  decisions  that  can  be  made  in  each  mission.  When 
planning  for  and  employing  the  special  forces  required  for  each  mission,  the  ability  to 
see  real-time  their  surrounding  beyond  line  of  sight  will  give  them  an  advantage  over 
adversaries  that  only  assume  line  of  sight  capabilities  when  no  larger  aircraft  are  available. 
Employment  of  forces  to  areas  of  unknown  conditions  may  increase  since  they  would  now 
have  independent  real-time  intelligence  gathering  assets.  Before,  teams  were  limited  by 
their  access  to  intel  gathering  assets  at  the  local  command  level  rather  than  at  the  team 
level  itself. 

Education  of  the  team,  unit,  and  command  leaders  will  also  need  to  include  this  new 
tactical  capability.  In  much  the  same  way  that  leaders  are  aware  of  the  capability  that  a 
sniper  or  a  machine  gunner  brings  to  a  small  tactical  team,  the  awareness  of  the  ability 
to  see  beyond  the  line  of  sight  would  need  to  be  instilled  in  the  emerging  leaders  of  the 
Special  Forces  functional  area. 

4.4.5  Personnel.  Personnel  changes  would  be  dependent  on  the  manner  in 
which  the  ISR  MAV  is  to  be  employed.  If  the  capability  is  to  be  assigned  to  one  member  of 
a  tactical  team  then  there  is  the  possibility  of  a  specialty  code  emerging  for  the  operation 
of  MAVs  (much  like  a  sniper,  machine  gunner,  etc.).  The  rest  of  the  team  would  still 
be  required  to  be  minimally  trained  on  the  system  in  case  of  contingencies.  If,  however, 
the  intent  is  for  every  member  of  a  tactical  team  to  have  the  ISR  MAV  capability,  then 
personnel  impacts  would  be  minimal.  It  would  simply  be  considered  another  part  of  their 
tactical  training  skill  set. 
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4.4.6  Facilities.  Facilities  for  the  ISR  MAV  would  be  minimal.  They  would  be 
largely  dependant  on  how  their  development,  sustainment  and  logistics  are  managed.  If 
their  development  is  absorbed  by  existing  developmental  organizations,  then  the  facilities 
would  already  be  handled.  The  same  would  apply  for  a  sustainment  organization 
(dedicated  or  basket  SPO).  Parts  for  the  ISR  MAV  would  need  to  be  housed  in  various 
locations.  War  ready  reserves  would  need  to  be  housed  in  theater  for  quick  access  and 
use.  Excessive  stockpiles  of  parts  are  not  envisioned  as  part  of  the  logistics  planning,  and 
so  warehouse  storage  beyond  normal  programmed  supply  limits  would  not  be  needed.  The 
production  contractor  (if  a  Contractor  Logistics  Support  (CLS)  contract  is  used),  the  depot 
repair  facility,  or  the  Defense  Logistics  Agency  (DLA)  would  absorb  the  necessary  parts 
to  maintain  the  ISR  MAV. 

4.5  Future  Capabilities  and  Technologies 

4.5.1  Future  Capability  Discussion.  The  MAV  concept  has  the  potential  to 
provide  many  other  mission  capabilities  outside  of  those  discussed  thus  far.  This  section 
concentrates  on  these  future  mission  capabilities  and  how  they  influence  the  baseline 
architecture  produced  in  this  thesis.  These  capabilities  are  grouped  into  three  categories 
based  on  implementation  timeline.  Short-term  is  considered  within  the  next  five  years. 
Mid-term  is  between  five  to  ten  years  and  long-term  is  greater  than  ten  years.  This  is 
a  general  timeline  in  which  user  needs  and  technological  development  will  effect  which 
capabilities  will  be  pursued  as  well  as  when  they  will  become  available.  Some  of  these 
capabilities  are  already  available  in  other  larger  UAVs  or  manned  platforms;  however, 
further  technological  improvements  must  occur  for  the  capabilities  to  meet  the  unique 
payload  requirements  of  the  MAV. 

These  possible  future  mission  capabilities  are  outlined  in  Ligure  4.22.  These  future 
capabilities  and  their  descriptions  are  based  on  general  user  need  trends,  current  manned 
platform  capabilities,  and  the  DoD’s  UAV  Roadmap  2002  [12].  Listed  below  are  the 
general  descriptions  of  each  future  capability.  The  ISR  MAV  architecture  was  reviewed 


4-39 


for  applicability  of  each  of  the  proposed  future  capabilities  and  and  changes  required  are 
noted.  Most  of  these  future  capabilities  only  require  wording  changes  for  the  architecture 
data  links,  information  exchanges,  and  needlines.  If  these  future  capabilities  are  pursued, 
the  baseline  architecture  products  need  to  be  more  in  depth  and  the  lower  system  levels 
and  associated  data  descriptions  need  to  be  refined  for  component-level  design. 


Future  Mission  Capability  Timeline 

_ (grouped  in  short/mid/long  terms) _ 


Short 

Term 


Acquire  Precise  Target  Coordinates 
Biological  and  Chemical  Delivery  Platform 
Biological  and  Chemical  Sniffer  Platform 
Communication  Eavesdropping 
Mobile  Ground  Station  When  Deployed 
Night  Reconnaissance 
Psychological  Operations 
Target  Tracking  or  Following 


Mid 

Term 


Long 

Term 


Air-to-Air  or  Anti-MAV 
Communication  Relay 
Distinguish  Facial  Features 
GPS  Jamming 
IR  Reconnaissance 

Locate  Targets  Through  General  Land  Obstacles 
Small  Ordinance  Delivery  Platform 
Suppression  of  Enemy  Air  Defenses 
Target  Painting 
Weather  Intelligence  Platform 


Electronic  Signal  Directional  Finding 
Land  or  Sea  Mine  Scout 
Target  Identification  and  Tracking 


Figure  4.22  Future  Mission  Capability  Timeline 

Short  Term  Mission  Capabilities: 

1 .  Acquire  Precise  Target  Coordinates 

This  capability  enables  the  user  to  obtain  more  precise  coordinates  on  a  target 
using  an  MAV.  Currently  users  can  get  a  general  idea  of  the  targets  location  by 
observing  the  MAVs  current  position.  This  current  method  is  not  accurate  enough 
for  guided  precision  munitions  or  reliable  target  tracking.  Implementation  examples 
can  include  measuring  the  distance  and  angle  of  the  target  relative  to  the  MAV 
and  then  performing  calculations  using  the  MAVs  GPS  position  to  determine  the 
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targets  location.  If  using  GPS  to  acquire  a  targets  location,  the  use  of  a  dual  band 
receiver  is  necessary  in  order  to  obtain  the  needed  precision.  The  additional  signal 
processing  for  coordinate  generation  is  the  primary  requirement  change  for  this 
capability.  The  extra  signal  processing  can  be  handled  by  either  the  air  platforms 
Payload  or  ground  units  Signal/Data  Processor ,  therefore  this  capability  will  not 
require  any  baseline  architectural  changes. 

2.  Biological  and  Chemical  Sniffer  Platform 

Giving  an  MAV  the  ability  to  detect  harmful  biological  or  chemical  weapons  will 
give  ground  units  more  time  to  prepare  for  protection  or  even  enable  the  units  to 
move  to  a  safer  location.  Termed  a  sniffer,  this  biological  or  chemical  detector 
could  be  attached  as  a  payload  or  even  refined  to  be  apart  of  the  air  platform  such 
that  other  payloads  could  still  be  attached.  Since  this  capability  could  be  considered 
a  simple  sensor,  it  would  operate  within  the  current  ISR  MAV  architecture  (where 
currently  the  image  capture  sensor  is  represented),  therefore  this  capability  will  not 
require  any  baseline  architectural  changes.  If  it  is  packaged  with  the  air  platform 
however,  a  system  will  need  to  be  added  to  the  MAV  operational  and  system  nodes 
to  reflect  the  added  sniffer  system. 

3.  Communication  Eavesdropping 

A  MAV  can  be  used  to  eavesdrop  on  enemy  communications  by  either  collecting 
transmitted  signals  (includes  directionally  transmitted  signals),  monitoring  wired 
communications,  or  collecting  voice  conversations.  The  MAV  can  accomplish  this 
capability  acting  as  the  collector  deploying  sensors,  or  both.  This  allows  special 
operations  units  to  operate  at  safe  distances  and  in  a  more  preferred  location  when 
conducting  communications  intelligence  (COMINT).  This  capability  can  require 
baseline  architectural  changes  depending  on  the  employment  method.  In  general, 
the  COMINT  system  used  can  be  included  as  apart  of  the  Payload  system. 

4.  Mobile  Ground  Station  When  MAV  Deployed 

Having  the  capability  to  relocate  the  ground  station  while  the  air  platform  is 
deployed  is  of  great  benefit  to  the  user.  Current  architecture  reflects  only  the  MAV 
requiring  external  navigation  information,  if  the  ground  unit  also  receives  this 
information,  it  could  be  tied  to  a  digital  moving  map  based  on  where  the  ground 
unit  is  while  also  showing  the  MAVs  location.  This  added  capability  enhances 
the  ground  unit’s  situational  awareness  and  increases  mission  effectiveness.  It 
will  require  more  optimized  systems  (size,  weight,  power,  etc.)  be  developed  in 
order  to  support  the  mobile  user;  however,  these  systems  and  interfaces  are  already 
architected  in  the  ISR  MAV  model.  This  capability  requires  little  architectural 
changes,  mainly  the  addition  of  an  information  exchange  between  the  Friendly 
Ground  Unit  and  GPS  Satellites  nodes. 
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5.  Night  or  IR  Reconnaissance 

This  capability  acts  as  an  improvement  to  the  over-the-hill  reconnaissance  scenario 
in  the  sense  that  it  enables  the  user  to  conduct  reconnaissance  at  night  or  during 
periods  of  low  light.  Optimized  night  vision  systems  need  to  be  developed  to  give 
the  user  the  capability  to  conduct  reconnaissance  when  they  need  it  most.  Since 
this  capability  is  simply  the  inclusion  of  a  different  payload  sensor,  no  architectural 
changes  are  necessary.  The  system  interfaces  and  data  links  are  already  modeled. 

6.  Psychological  Operations 

The  capability  to  perform  psychological  operations  is  a  very  broad  capability  and 
spans  many  different  missions.  Considered  in  this  thesis  is  the  ability  to  send  a 
“message”  to  the  enemy  or  non-combatants  that  another  military  force  is  present 
in  the  area  and  that  they  are  being  watched.  Also  considered  is  the  ability  to  drop 
propaganda  leaflets  as  well  as  to  serving  as  an  unknown  weapon,  meaning  ground 
observers  may  be  unaware  of  whether  or  not  it  is  armed.  This  capability  may 
require  architectural  changes  depending  on  the  psychological  mission  pursued.  If 
only  a  message  of  US  forces  present  is  sought,  the  current  ISR  MAV  capability  can 
perform  that  mission  in  its  current  configuration.  If  the  mission  would  require  the 
delivery  of  leaflets  or  other  objects,  the  architecture  would  need  to  include  a  payload 
release  function  and  data  elements  that  would  transmit  the  release  commands. 

7.  Target  Tracking  or  Following 

The  capability  for  a  MAV  to  accurately  track  or  follow  an  assigned  enemy  target 
will  keep  the  ground  unit  up-to-date  on  enemy  movement  and  increase  their 
situational  awareness.  This  ability  to  track  or  follow  a  target  should  be  automated 
so  the  user  can  continue  with  the  mission  and  remain  mobile  (in  a  way  ties  to 
the  Mobile  Ground  Station  When  Deployed  capability).  This  capability  focuses 
on  tracking  only  one  target,  multiple  target  tracking  is  addressed  in  the  Target 
Identification  and  Tracking  capability.  Signal  processing  and  target  movement 
detection  systems  would  need  to  be  greatly  enhanced  and  refined  to  meet  the 
payload  size  and  demands.  Assuming  the  enhanced  processing  and  detection  could 
be  achieved,  this  capability  would  not  require  any  baseline  architectural  changes. 
The  processing  and  detection  functions  would  be  enabled  by  the  existing  signal 
processor,  payload  sensor,  and  respective  data  links. 

Mid  Term  Mission  Capabilities: 

1 .  Air- to- Air  or  Anti-MAV 

Historically,  manned  aircraft  were  utilized  as  reconnaissance  platforms,  transformed 
to  ground  attack  units  and  then  employed  as  air-to-air  fighters.  MAVs  and  UAVs 
have  started  the  same  trend  as  some  UAVs  are  now  seeing  the  air-to-ground  attack 
role.  The  capability  of  air-to-air  MAV  or  Anti-MAV  enables  force  protection 
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against  enemy  MAV  capabilities.  This  includes  MAVs  designed  to  attack  other 
enemy  MAVs  (air-to-air)  or  simply  ground  units  attacking  enemy  MAVs  (surface- 
to-air).  With  the  rise  of  MAV  interest,  the  need  for  this  capability  is  not  far  off. 
Technical  issues  such  as  how  to  quickly  locate  an  enemy  MAV,  what  kind  of 
weapons  would  be  the  most  effective,  and  what  air-to-air  tactics  to  use  necessitates 
further  exploration.  This  capability  requires  changes  to  the  baseline  architecture. 
The  developed  capability  needs  will  determine  the  necessary  changes.  Some 
basic  architecture  changes  that  are  foreseen  already  are  the  addition  of  a  function 
to  employ  an  attack  mechanism  against  the  enemy  MAV  and  the  associated 
data/command  links  to  enable  such  a  function;  whether  it  is  on  the  MAV  or  the 
ground  system. 

2.  Communication  Relay 

This  capability  gives  the  user  the  ability  to  increase  their  communications  range 
and,  if  properly  implemented,  can  lower  the  probability  of  intercept  and  detection. 
One  way  to  increase  the  range  of  a  communications  device  is  to  send  a  MAV 
into  the  air  to  act  as  a  network  link  which  receives  data  from  the  ground  unit  then 
transmits  it  to  the  receiver.  This  enhances  such  communication  systems  that  require 
line  of  sight  or  that  experience  degradation  due  or  loss  due  to  terrain.  Technical 
issues  such  as  how  to  give  the  MAV  enough  power  to  perform  this  mission  need  to 
be  worked  out.  Another  way  to  deploy  a  MAV  as  a  communications  relay  is  to  relate 
it  to  a  messenger  bird  such  that  the  MAV  stores  the  data  to  be  communicated  and  is 
instructed  where  to  go  for  transmission.  This  keeps  the  ground  unit  electronically 
concealed  from  the  enemy  because  the  MAV  is  flying  to  a  safer  broadcast  area. 
This  capability  will  not  require  architectural  changes,  mainly  the  payload  system 
will  pick  up  the  responsibility  of  storing  communication  data  as  well  as  processing 
basic  commands  and  protocols. 

3.  Distinguish  Facial  Features 

The  ability  to  distinguish  human  facial  features  will  greatly  improve  the  capability 
to  detect  and  track  targets  as  well  as  search  out  particular  enemies.  This  capability 
includes  the  MAV  searching  for  a  particular  person  by  analyzing  facial  features 
when  searching  enemy  targets  and  labeling  them  as  ‘possible  enemy  personnel’. 
No  architectural  changes  will  be  needed;  the  recognition  system  or  enhanced 
processing  power  can  be  added  as  a  Payloadto  the  MAV. 

4.  GPS  Jamming 

The  capability  to  deny  enemy  forces  access  to  GPS  data  can  be  accomplished  using 
a  MAV.  This  capability  will  also  jam  the  current  architected  source  for  navigation 
information  and  would  require  a  coupled  secondary  navigation  capability  (improved 
inertial  navigation  system,  terrain  mapping,  etc).  The  GPS  jammer  can  be  added  as 
a  Payload  and  an  INS  or  other  non-GPS  dependant  navigation  system  will  need  to 
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be  added  to  the  Air  Vehicle  system.  The  non-GPS  navigation  system  may  require 
architecture  changes  based  on  what  data  links  are  required  to  perform  navigation. 
These  could  include  data  links  to  additional  sensors  in  the  MAV  payload,  or  data 
links  to  the  operator  that  would  perform  as  a  origin  point  for  navigation  reference. 

5.  IR  Reconnaissance 

The  capability  to  conduct  infrared  (IR)  reconnaissance  will  greatly  improve  the 
over-the-hill  reconnaissance  missions,  as  well  as  any  other  operating  scenario. 
Such  thermal  imaging  systems  will  enable  the  MAV  to  see  during  the  night  as 
well  as  in  most  poor  weather  conditions.  This  capability  also  enhances  the  ability 
to  detect,  track,  and  identify  critical  targets.  Current  IR  systems  will  first  need 
to  be  miniaturized  and  require  lower  power  to  conform  to  the  MAV’s  payload 
constraints.  Since  the  IR  system  could  be  placed  in  the  current  ISR  MAV  payload 
sensor  construct,  no  architectural  changes  are  necessary  for  this  capability. 

6.  Locate  Targets  Through  General  Land  Obstacles 

The  capability  to  locate  targets  through  general  land  obstacles  such  as  trees  is 
being  pushed  as  a  need  from  the  user  community  [12].  A  MAV  with  such  ability 
to  see  through  trees  or  other  general  land  obstacles  greatly  increases  the  chance 
of  locating  an  enemy  when  performing  area  surveillance  or  reconnaissance.  Such 
technological  issues  like  what  systems  to  use,  what  amount  of  image  processing 
is  necessary,  and  possible  error  sources  need  to  be  researched.  No  architectural 
changes  are  expected,  however  minimal  changes  may  be  necessary  based  on  a  more 
refined  capability  description. 

7.  Small  Ordinance  Delivery  Platform 

This  capability  allows  a  MAV  to  serve  as  an  air-to-ground  attack  vehicle  either 
through  weapon  delivery  or  by  itself  acting  as  the  ordinance.  Users  will  be  able  to 
search  and  perform  reconnaissance  while  retaining  the  option  to  attack  or  run  into 
the  enemy.  This  capability  can  be  implemented  currently  but  to  create  an  adequate 
impact  on  the  enemy,  the  small  ordinances  must  be  lighter  and  more  destructive.  If 
the  MAV  is  to  be  used  as  an  ordinance  itself,  no  architectural  changes  are  needed, 
but  a  less  elaborative  Air  Vehicle  system  could  be  used  to  decrease  costs.  If  the 
MAV  is  to  actually  deliver  ordinance,  then  a  system  function  of  ordinance  release 
is  needed  as  well  as  the  data  elements  to  impart  the  release  commands. 

8.  Suppression  of  Enemy  Air  Defenses 

With  the  SEAD  capability,  a  MAV  can  help  ground  units  locate  an  enemy  air 
defense  system  by  either  ‘homing  in’  on  its  active  radar  or  simply  performing 
visual  reconnaissance.  The  MAV  could  also  act  as  an  anti-radiation  missile  if 
this  capability  is  coupled  with  the  small  ordinance  delivery  platform  capability. 
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However,  this  seems  to  turn  the  MAV  into  more  of  a  short  range  munition  rather 
than  an  air  platform.  If  this  was  added  as  an  optional  ‘payload’  then  the  MAV 
still  acts  as  a  multi-purpose  air  vehicle.  This  capability  will  not  require  direct 
architectural  changes;  however  certain  activity  changes  and  information  flows  in 
the  OV-5  and  OV-6C  will  need  to  be  made. 

9.  Laser  Designation  of  Targets 

The  term  target  painting  or  lasing  generally  involves  a  laser  pointing  to  a  target 
while  a  weapon  delivered  from  a  delivery  platform  follows  the  laser  to  the  target. 
Currently,  ground  units  pack  in  equipment  to  laser  designate  a  target  but  if  a  MAV 
is  also  being  packed  in,  it  makes  sense  to  have  the  MAV  also  complete  this  task, 
thus  eliminating  a  system  having  to  be  carried  in  (if  the  MAV  has  the  capability  to 
swap  out  payloads).  This  capability  keeps  friendly  ground  units  at  safer  distances 
from  the  target.  Technical  issues  to  be  resolved  are  developing  a  sufficiently 
powered  laser  to  conform  to  the  MAV  form  factor.  This  capability  requires  minor 
architectural  changes  with  the  addition  of  a  Target  and  Ordinance  Entity  external 
node  as  well  as  more  emphasis  on  the  need  for  information  exchange  between  the 
Friendly  Ground  Unit  and  Strike  Assets. 

10.  Weather  Intelligence  Platform 

The  capability  for  an  MAV  to  gather  weather  intelligence  information  will  aid 
ground  units  that  already  conduct  such  missions  as  well  as  give  other  units  this 
capability  as  well.  As  the  name  states,  the  capability  to  gather  weather  intelligence 
includes  anything  from  humidity,  temperature,  wind  speeds,  and  other  information 
that  would  be  of  use  to  the  user.  This  capability  requires  minor  architectural 
changes,  mainly  on  the  OV-5  activity  and  OV-6C  event  diagrams  to  reflect  the 
sampling  and  tracking  of  the  weather  conditions. 

11.  Operation  in  Urban  or  GPS  Denied  Environments 

This  is  one  of  the  most  challenging  missions  for  the  current  generation  of 
MAVs.  Urban  environments  are  challenging  due  to  the  proliferation  of  obstacles. 
These  obstacles  prevent  line-of-site  communication  and  increase  the  chance  of  a 
collision.  To  operate  in  this  environment,  MAVs  must  be  equipped  with  collision 
avoidance  sensors  and  some  type  of  communication  method  that  allows  line-of-site 
communication.  Another  solution  to  the  line-of-site  problem  is  to  implement  a 
communication  relay  MAV  that  could  loiter  above  the  urban  environment  to  relay 
information  to  and  from  MAV.  GPS  denied  areas  require  MAVs  to  have  a  secondary 
source  of  navigation  data.  This  could  be  something  similar  to  the  Digital  Terrain 
Elevation  Database  or  some  kind  of  intelligent  mapping  software.  The  MAV  must 
have  a  way  of  knowing  where  it  is  to  operate  correctly.  Adding  the  capability 
to  operate  in  these  adverse  environments  affects  the  architecture  by  requiring  the 
addition  of  new  communication  lines  and  nodes  to  reflect  the  additional  sensor  data 
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or  navigation  processor. 


Long  Term  Mission  Capabilities:  All  long  term  mission  capabilities  listed  here 
will  require  major  technological  improvements  and  breakthroughs  as  well  as  a  large  push 
from  the  user  community  before  they  can  be  pursued.  Due  to  this,  no  architectural  changes 
have  been  listed  for  any  of  the  long  term  capabilities  because  technology  and  user  needs 
will  drive  the  changes  needing  to  be  made. 

1.  Electronic  Signal  Directional  Finding 

In  this  capability,  a  MAV  is  able  to  locate  enemy  broadcasting  electronic  signals. 
Such  applications  can  include  searching  for  enemy  jammers,  radars,  other  MAV 
operators,  or  whatever  the  sensor  is  tuned  to  pick  up.  With  this,  ground  units  will 
be  able  to  conduct  electronic  reconnaissance  or  anti-electronic  warfare.  There  are 
many  technological  improvements  that  must  occur  before  this  MAV  capability  can 
be  realized. 

2.  Land  or  Sea  Mine  Scout 

This  capability  allows  a  MAV  to  search  out  either  land  or  sea  based.  The  MAV 
would  be  packaged  with  sensors  capable  of  locating  and  identifying  possible  mines. 
Users  could  deploy  the  MAV  with  such  capability  to  scout  ahead  of  the  planned 
route  and  relay  back  information  if  a  mine  is  discovered. 

3.  Target  Identification  and  Tracking 

The  Target  Identification  and  Tracking  capability  takes  the  short  term  Target 
Tracking  or  Following  capability  and  adds  target  identification  to  it.  This  gives  the 
ground  units  a  more  capable  and  autonomous  MAV  that  is  not  only  able  to  track  the 
enemy  but  also  identify  it.  Identification  can  be  conducted  through  a  wide  range 
of  sensors  that  detect  optical,  IR,  or  acoustic  properties.  One  of  the  end  goals  for 
any  ground  unit  is  to  know  the  location  and  status  of  enemy  forces,  so  ideally  a 
spin-off  of  this  capability  is  multiple  target  identification  and  tracking  with  a  MAV 
(or  multiple  networked  MAVs).  Such  capability  helps  lift  the  ‘fog  of  war’  and  gives 
friendly  forces  the  upper  hand. 

4.  Localized  Deployment  with  External  Control 

This  capability  reflects  a  fundamental  shift  in  how  the  information  from  the  MAV 
and  control  of  the  MAV  is  handled.  This  capability  enables  an  external  source 
(another  unit,  a  forward  air  controller,  Joint  STARS,  AWACS,  etc)  to  control 
the  flight  plan  of  the  MAV  once  the  ground  user  launches  the  MAV.  The  current 
architecture  assumes  the  MAV  is  only  controlled  by  the  user  so  provisions  for 
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handing  off  control  of  the  MAV  need  to  be  implemented.  A  second  component 
of  this  capability  is  to  have  the  data  from  the  MAV  be  routed  directly  to  external 
sources.  This  baseline  architecture  assumes  the  data  must  pass  through  the 
ground  station  operator  prior  to  dissemination  to  external  sources.  Thus,  all  of  the 
communication  lines  which  pass  from  the  MAV  to  the  ground  station  node  must 
also  be  sent  to  the  external  user.  Implementing  this  capability  affects  basically 
every  diagram  in  the  architecture. 


4.5.2  Future  Technology  Discussion.  After  listing  the  possible  future  MAV 
mission  areas  it  is  apparent  that  some  of  the  key  technologies  driving  the  mission  need  to 
be  listed.  The  future  technologies  were  generated  by  observing  and  analyzing  the  users 
background  and  capability  deficiencies  (Section  2.1),  the  baseline  architectures  (Section 
4.3),  and  the  future  capabilities  (Section  4.5.1).  Some  technologies  are  not  directly 
apparent  through  the  analysis  and  were  retrieved  from  cited  sources.  These  technologies 
are  placed  into  two  separate  categories  based  on  how  well  they  benefit  the  current  and 
future  mission  areas  mentioned  throughout  this  research.  The  first  category  (Figure  4.23), 
lists  those  technologies  that  most  benefit  the  future  mission  areas  while  the  second  (Figure 
4.24),  lists  those  that  are  not  directly  related  to  the  mission  areas  but  are  still  important 
to  the  development  of  the  MAV  and  its  missions.  For  the  first  set  of  technologies,  a  brief 
description  is  provided  to  help  demonstrate  their  importance  in  enabling  or  improving  a 
MAVs  mission  area. 

1 .  Enhanced  Optical  Sensor  Capabilities 

Current  MAV  applications  and  capabilities  use  onboard  optical  sensors,  or 
cameras,  for  reconnaissance.  To  improve  these  sensors,  new  capabilities  could 
be  added  such  as  optical  zooming,  camera  slewing,  or  automatic  focusing.  Such 
added  technologies  will  improve  the  MAVs  operational  effectiveness  and  suitability. 

2.  Mobile  Ground  Station  When  MAV  Deployed 

Having  GPS,  or  another  navigation  source,  integrated  into  the  ground  station 
enables  the  operator  to  view  their  location  in  respect  to  the  MAVs.  This  means 
that  both  the  location  of  the  operator  and  MAVs  is  displayed  through  the  human 
interface.  With  this,  a  better  sense  of  situational  awareness  and  increased  mobility 
can  be  achieved. 


4-47 


Future  MAV  Technology  Capabilities 


Enhanced  Optical  Sensor  Capabilties 
GPS  Integration  into  Ground  Station 
Integrated  Ground  Station 
Low  Light  Emitting  Display 
Low  Probability  of  Intercept  Communications 
Modular  and  Swappable  Payloads 
Multiple  Sensor  Payload 
Non-Line-Of-Sight  Communications 
Reduce  DTED  Level  2  in  Real-Time 
Sensor  and/or  Image  Stabilization 


Figure  4.23  Future  MAV  Technologies 

3.  Integrated  Ground  Station 

This  technology  includes  integrating  all  systems  needed  by  the  ground  station  into 
a  single  system  that  is  lightweight  and  easily  packable  by  a  single  user.  An  example 
is  having  the  transmitter,  receiver,  power  supply,  and  human  interface  integrated 
into  a  single  unit  that  is  the  size  of  a  PDA.  Several  technological  improvements 
in  the  realm  of  miniaturization  and  power  supplies  will  need  to  occur  before  such 
capability  can  be  pursued. 

4.  Low  Light  Emitting  Display 

Night  operations  require  the  operators  to  remain  hidden  and  avoid  disclosing 
their  position  to  enemy  forces.  If  a  MAV  is  to  operate  in  night-time  or  low 
light  environments,  then  the  user  interface  needs  to  conform  to  the  concealment 
requirement.  To  do  this,  the  user  interface  display  unit  needs  to  emit  little  or  no 
light  beyond  what  is  necessary  for  the  user.  Current  technologies  offer  solutions  to 
enable  this  capability  such  as  helmet  mounted  displays  used  in  aircraft  or  even  a 
small  monocle-type  display  that  fits  over  the  user’s  eye. 

5.  Low  Probability  of  Intercept  Communications 

In  Section  2.1.2,  it  was  mentioned  that  special  reconnaissance  teams  required 
the  need  for  long  range  and  low  probability-of-intercept  radios  to  improve  their 
mission  effectiveness.  This  requirement  is  intended  for  transmission  between  the 
ground  force  and  higher  headquarters;  however,  it  should  also  be  the  case  for 
ground  to  MAV  communication.  Without  a  communication  system  having  a  low 
probability-of-intercept,  the  enemy  can  triangulate  the  units  location  or,  at  the  very 
least,  know  there  is  a  unit  in  the  vicinity  -  eliminating  the  element  of  surprise. 
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6.  Modular  and  Swappable  Payloads 

Modular  and  swappable  payloads  involve  the  operator  being  able  to  change  a  MAVs 
payload  before  or  after  flight.  An  example  could  be  that  the  operator  carries  an 
optical  payload,  an  ordinance  delivery  payload,  and  a  chemical  detection  payload 
for  the  MAV.  The  operator  then  decides  which  payload  to  attach  to  the  MAV  before 
launching.  This  technology  allows  the  operator  to  freely  choose  the  payload  based 
on  the  current  threat  or  battlefield  situation. 

7.  Multiple  Sensor  Payload 

Having  multiple  sensors  in  a  single  payload  increases  mission  efficiency  while  the 
MAV  is  in-flight.  A  simple  example  of  this  is  a  payload  that  contains  both  chemical 
detection  equipment  and  optical  sensors  such  as  a  reconnaissance  camera.  One 
use  for  such  a  payload  could  be  to  alert  the  operator  of  a  presence  of  a  harmful 
chemical  while  conducting  video  reconnaissance.  There  are  many  different  sensor 
combinations  possible.  Determining  which  combinations  are  best  suited  for  the 
current  mission  will  be  based  on  the  operator  and  the  mission  environment. 

8.  Non-Line-Of-Sight  Communications 

As  the  MAV  increases  its  range  and  maneuverability,  especially  in  urban 
environments,  communications  that  do  not  require  line-of-sight  will  become 
a  greater  user  need.  With  these  non-line-of-sight  communications,  operators 
can  remain  in  a  concealed  area  without  having  to  relocate  to  keep  the  MAVs 
signal.  Current  technologies  can  enable  such  capability  but  are  not  yet  feasible  to 
implement  on  a  MAV. 

9.  Reduce  DTED  Level  2  in  Real-Time 

Incorporating  the  digital  terrain  elevation  database  (DTED)  into  the  MAVs 
navigation  system  will  allow  the  system  to  have  a  sense  of  height  above  ground. 
Current  architectures  assume  GPS  as  the  sole  input  to  the  navigation  system. 
However,  this  could  be  augmented  if  both  GPS  and  DTED  are  implemented  to 
allows  the  MAVs  position  to  be  calculated  (GPS)  along  with  its  elevation  above 
ground  (DTED).  Due  to  current  payload,  signal  processing,  and  power  constraints 
onboard  the  air  platform,  a  short  term  solution  could  be  to  keep  GPS  onboard  while 
DTED  is  integrated  into  the  ground  station  signal  processor  unit.  With  this,  the  air 
platforms  position  would  be  sent  to  the  ground  station  and  as  an  acknowledgement 
the  elevation  for  that  position  could  be  sent  back  to  the  air  platform.  The  current 
resolution  of  DTED  Level  2  is  approximately  30  meters  in  altitude  (highest  DTED 
level  to  date),  which  is  good  enough  for  a  larger  UAV  or  manned  aircraft  but, 
depending  on  the  MAVs  application,  may  not  be  good  enough.  Future  DTED  levels 
such  as  Level  5  with  its  proposed  1  meter  resolution  will  better  suit  the  MAV. 
However,  if  resolution  increases  to  this  level,  the  file  size  is  likely  to  be  very  large 
(requiring  more  storage  space  or  portable  media  containing  data  for  a  particular 
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geographical  area).  Terrain  mapping  can  be  a  derived  technology  once  DTED 
Level  2  is  incorporated,  however  this  mapping  technology  will  be  limited  based  on 
resolution  available  and  processing  speed. 

10.  Sensor  and/or  Image  Stabilization 

Adding  sensor  or  image  stabilization  to  a  MAV  will  aid  the  operator  by  identifying 
targets  faster  and  more  accurately.  Stabilization  can  either  occur  onboard  the  air 
platform  or  at  the  ground  stations  signal  processor.  Results  will  most  likely  be 
better  if  stabilization  takes  place  onboard  the  platform  but  there  are  techniques  that 
could  be  incorporated  into  the  ground  station  signal  processor.  An  example  of  an 
onboard  stabilization  system  could  include  a  camera  mounted  to  a  pod  where  the 
pod  rotated  based  on  the  airframes  change  in  pitch,  roll,  or  yaw.  For  the  ground 
based  system,  an  example  is  that  a  computer  could  take  picture  stills  from  the 
incoming  video  such  that  the  operator  does  not  notice  the  image  bouncing  around 
as  much.  Such  sensor  stabilization  aids  mainly  by  reducing  operator  fatigue  while 
enabling  faster,  more  accurate  target  identification. 


Other  Possible  Future  MAV  Technologies 


Common  Power  supply  system  for  all  ground  based  systems 
Communications  Intelligence  (COMINT)  sensors 
Daylight  Imaging  System  (DIS) 

Diesel  Powerplant 

Enhanced  Aerodynamics  for  increased  lift  and  power  efficiency 
Enhanced  Battery  Power 

Enhanced  Field  of  View  optical  sensors  or  sensor  array 
Fuel  Cells 

Forward  looking  infrared  (FUR) 

HFA/HF/UHF  Directional  Finding  Equipment 
Increased  Data  Processing  (lightweight,  low  power) 
Infrared  line  scanner  (IRLS) 

Reduce  DTED  Level  5  data  in  near  real  time 
SATCOM 

Small,  Low  Power  Lasers  (for  range  finding,  target  designation) 
Small,  Low  Power  Optical  Sensors  for  Night  Vision 
Solar  Power  (alternate  fuel  or  in  flight  recharge) 
Synthetic  Aperture  Radar  (SAR) 


Figure  4.24  Other  Possible  Future  MAV  Technologies 
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As  discussed,  there  are  ample  areas  of  study  and  research  that  provide  both  near- 
term  and  long-term  benefits  to  the  operational  MAV  community.  While  an  attempt  was 
made  to  delineate  which  areas  are  more  attainable  in  the  various  time  spaces,  it  will 
ultimately  be  the  operational  community  along  with  identified  capability  gaps  that  will 
guide  which  technologies  are  actively  pursued. 
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V.  Conclusions  and  Recommendations 


5.1  Conclusions 

The  goal  of  this  thesis  was  to  apply  good  systems  engineering  principles  to  develop 
a  mini/micro  unmanned  aerial  vehicle  (MAV)  architecture  model  describing  their  use  in 
three  separate  but  closely  related  mission  areas:  Over-the-Hill-Reconnaissance,  Battle 
Damage  Information  (BDI),  and  Local  Area  Defense  (LAD).  These  mission  areas  are 
derived  from  the  special  operations  forces  (SOF)  background,  mission  tasks,  and  their 
capability  deficiencies  presented  in  Chapter  II.  The  general  terms  of  unmanned  aerial 
vehicle  (UAV)  and  MAV  were  introduced  to  provide  insight  into  the  system  architecture 
used  to  fulfill  the  special  operations  forces  capability  deficiencies.  With  an  increased 
understanding  of  the  user,  their  operating  environment,  and  the  general  concepts  of  both 
UAVs  and  MAVs,  this  thesis  was  scoped  to  architecting  a  single-man-packable  and  single¬ 
man-operable  intelligence,  surveillance,  reconnaissance  (ISR)  MAV  system  that  does  not 
require  the  carrier  to  sacrifice  normal  mission  essential  gear.  Architecturally,  the  MAV 
system  was  defined  to  contain  two  cohesive  elements,  an  airborne  and  a  ground  element, 
where  both  elements  are  required  for  mission  operation. 

Such  a  MAV  system  is  designed  to  meet  current  capability  needs;  however,  a 
proper  system  engineering  architecture  approach  is  needed  since  missions  and  operating 
environments  often  change.  Likely  changes  include  systems  that  are  needed  to  interface 
with  the  MAV  as  well  as  updated  user  requirements.  Applying  a  uniquely  designed  MAV 
to  a  changing  environment  is  more  likely  to  require  a  new  system  rather  than  modifying 
a  current  one.  With  the  use  of  the  systems  architecture  approach,  the  MAV  system  could 
be  designed  or  described  in  such  a  way  that  allows  for  future  refinement,  growth  and 
application. 

A  comprehensive  description  of  the  methodology  used  in  this  thesis  was  put  together 
in  Chapter  III  to  benefit  those  unfamiliar  with  the  architecture  models  of  systems  as 
well  as  the  many  different  forms  of  models  available.  This  methodology  included  the 
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traceability  approach  used  as  well  as  description  of  architecture  models  presented  in  the 
DoD  Architecture  Framework  (DoDAF).  Throughout  this  thesis,  traceability  was  a  key 
element  ensuring  that  the  architectures  developed  would  be  integrated.  This  began  with 
the  realization  that  a  capability  gap  exists  and  ends  by  defining  specific  functional  tasks. 

The  bulk  of  this  thesis  is  the  application  of  the  DoDAF  to  the  MAV  system.  Using 
the  methodology  formulated,  all  findings,  operating  scenarios,  system  traceability  efforts, 
and  resulting  architectures  were  presented.  These  results  enable  the  creation  of  a  set  of 
baseline  integrated  architecture  products  for  a  MAV  focused  in  the  ISR  realm.  To  further 
expand  and  make  this  effort  more  complete  Doctrine,  Organization,  Training,  Leadership 
and  Education,  Personnel,  and  Facility  (DOTLPF)  considerations  were  addressed,  and 
plausible  future  capabilities  and  technologies  were  discussed.  Through  the  use  of  the 
systems  engineering  process,  these  results  met  the  goal  of  this  thesis  by  providing  an 
integrated  MAV  architectural  model  describing  a  general  ISR  mission  with  emphasis  on 
three  mission  areas:  Over-the-Hill-Reconnaissance,  Battle  Damage  Information  (BDI), 
and  Local  Area  Defense. 

5.2  Remarks 

Due  to  the  refocus  on  Systems  Engineering  in  the  DoD,  integrated  architectures  are 
now  required  for  all  current  and  future  acquisition  programs.  The  products  presented  in 
Chapter  IV  can  be  applied  to  any  MAV  program  to  be  compliant  with  these  regulations. 
The  developed  architecture  products  also  present  the  first  academically  constructed  set  of 
architecture  products  for  a  real-world  capability. 

Creating  these  baseline  products  also  allows  the  designers  and  system  engineers 
to  further  decompose  the  system  into  the  key  measures  which  define  the  trade  space  for 
the  MAV  system.  These  key  measures  for  the  MAV  itself  are:  weight,  size,  level  of 
discrimination,  interoperability,  area  search  size  and  area  search  rate.  For  the  ground 
station,  they  are  portability,  size,  and  level  of  concealment.  Once  these  key  measures  are 
identified,  the  designers  can  then  derive  applicable  requirements  for  the  system  that  are 


5-2 


based  on  the  architecture  products  (interfaces,  information  exchanges,  operational  nodes, 
etc.)  as  well  as  any  specific  requirements  based  on  the  key  measures. 

5.3  Recommendations 

Following  this  research,  the  authors  recommend  that  the  sponsor  and  any  MAV- 
related  organizations  review  and  establish  this  ISR  MAV  architecture  as  the  baseline  for 
the  current  ISR  MAV  capability.  This  architecture  also  needs  to  be  reviewed  and  iteratively 
updated  to  reflect  how  ISR  MAVs  fit  into  the  mission  of  its  users.  As  with  any  effort  to 
model  a  system,  there  are  several  levels  of  detail  that  can  be  achieved  to  enable  a  more 
refined  view  of  the  system. 

Now  that  a  baseline  structural  model  has  been  developed  for  the  ISR  MAV,  temporal 
modeling  of  the  system  can,  and  should,  be  developed  that  will  better  describe  the 
performance  parameters  of  the  system.  The  static  model  presented  in  this  research 
forms  the  foundation  for  the  dynamic  models  that  can  be  used  to  fully  evaluate  the 
system’s  strengths  and  weaknesses  as  different  designs  are  tested.  Specific  instantiations 
of  this  architecture  can  also  be  researched  to  guide  development  of  other  members  of  the 
family  of  systems.  While  this  architecture  dealt  with  the  mission  areas  of  ISR,  related 
architectures  for  supporting  and  supported  missions  performed  by  MAVs  should  also  be 
developed.  All  of  these  architectures  and  the  linkages  between  them  will  truly  enable  an 
integrated  look  at  the  emerging  field  of  MAVs  in  the  DoD. 

5.4  Future  Areas  of  Study 

This  thesis  deals  mostly  with  the  Concept  of  Operations  and  the  resulting 
architectures  for  the  use  of  MAVs  in  the  US  Air  Force.  Its  scope  includes  only  single- 
man-packable/launchable  systems  and  is  the  first  of  its  type  to  academically  architect  the 
MAV  system.  The  following  areas  of  study  are  presented  either  because  they  fell  outside 
of  the  scope  of  this  thesis,  they  represent  further  study  of  threads  presented  in  this  thesis,  or 
simply  will  help  to  understand  and  integrate  the  use  of  MAVs  in  the  military  of  today  and 
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tomorrow.  The  future  areas  of  study  (FAS)  below  are  presented  with  the  understanding 
that  they  would  be  completed  in  and  with  the  focus  of  a  systems  engineering  approach 
unless  otherwise  stated. 

FAS1:  Swarming  MAV  detailed  architectures.  This  would  take  any  ”to-be” 
architectures  and/or  ConOps  developed  on  the  topic  and  fully  explore  the  ConOps, 
architectures,  behavior  rule  models,  and  challenges  facing  this  area  of  MAV  use. 

FAS  2:  Detailed  systems  architecture  of  the  miniaturization  of  remote  aerial  target 
designation  (lasing).  This  requires  study  and  description  of  the  target  designation  mission, 
functions,  current  technologies,  future  technologies,  and  the  challenges  facing  their 
miniaturization  to  a  MAV  level. 

FAS3:  DoD  integration  of  MAV  use.  Since  this  thesis  aimed  mostly  at  USAF 
missions  and  operations  to  develop  capabilities  and  ConOps,  this  area  of  study  would 
take  a  higher,  and  less  detailed  look  at  MAV  use,  but  with  a  purple  focus.  It  would  seek 
to  develop  what  high  level  architectures  would  need  to  be  agreed  upon  and  established  in 
order  to  better  integrate  the  use  of  MAVs  between  services. 

FAS4:  MAV  observation/targeting  stabilization  study  and  analysis.  This  FAS  would 
need  to  be  performed  by  an  aeronautical  engineering  Masters/Doctorate- seeking  student. 
The  study  would  use  the  currently  fielded  MAV  systems  as  a  baseline  and  seek  to  adjust 
various  design  characteristics  to  yield  the  most  stable  flight  platform  as  possible  to  provide 
useful  EO  intelligence.  Modeling,  wind  tunnel  testing  and  publishing  of  results  would  be 
of  great  benefit  to  the  currently  fielded  MAV  development  lab  and  SPO. 

FAS5:  Full  To-Be  MAV  architectures.  The  extension  would  develop  full 
architectures  of  proposed  future  capabilities  as  presented  in  Chapter  IV  of  this  thesis. 
While  the  future  capabilities  were  all  introduced  and  discussed  here,  a  full  compliment  of 
architecture  products  are  necessary  to  flush  out  implications  to  practical  MAV  application. 
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Appendix  A.  MAS/  List  of  Acronyms 


Table  A.l  -  List  of  Acronyms 


Acronym 

Description 

AF 

Air  Force 

AFMC 

Air  Force  Materiel  Command 

AFRL 

Air  Force  Research  Laboratory 

AFSOC 

Air  Force  Special  Operations  Command 

AFTL 

Air  Force  Task  List 

AOC 

Air  Operations  Center 

AV 

All  View 

BATCAM 

Battlefield  Air  Targeting  Camera  Autonomous  Micro  air 
vehicle 

BDA 

Battle  Damage  Assessment 

BDI 

Battle  Damage  Information 

C3 

Command,  Control,  Communications 

C4ISR 

Command,  Control,  Communications,  Computers, 

Intelligence,  Surveillance, 
and  Reconnaissance 

CAO 

Civil  Affairs  Operations 

CCT 

Combat  Controller 

CDD 

Capability  Development  Document 

CLS 

Contractor  Logistics  Support 

COMINT 

Communications  Intelligence 

COMM 

Communications 

CP 

Counter- Proliferation 

CPD 

Capability  Production  Document 

CT 

Counter  Terrorism 

DA 

Direct  Action 

DBMS 

Database  Management  System 

DIS 

Daylight  Imaging  System 

DLA 

Defense  Logistics  Agency 

DoD 

Department  of  Defense 

DoDAF 

Department  of  Defense  Architecture  Lramework 

DOTMLPF 

Doctrine,  Organization,  Training,  Materiel,  Leadership  and 
Education, 

Personnel,  and  Lacilities 

DTED 

Digital  Terrain  Elevation  Database 

EW 

Electronic  Warfare 

FID 

Loreign  Internal  Defense 

Continued  on  next  page 
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Table  A.l  -  continued  from  previous  page 


Acronym 

Description 

FLIR 

Forward  Looking  Infrared 

FoS 

Family  of  Systems 

GPS 

Global  Positioning  System 

HCI 

Human  Computer  Interface 

HF 

High  Frequency 

I/O 

Input  or  Output 

IA 

Integrated  Architecture 

ICD 

Initial  Capability  Document 

ICOM 

Input,  Control,  Output  and  Mechanism 

IEEE 

Institute  of  Electrical  and  Electronic  Engineers 

IMINT 

Information  Intelligence 

INS 

Inertial  Navigation  System 

10 

Information  Operations 

IR 

Infrared 

IRLS 

Infrared  Line  Scanner 

ISR 

Intelligence,  Surveillance,  Reconnaissance 

JCIDS 

Joint  Capabilities  Integration  and  Development  System 

JFC 

Joint  Functional  Concept 

LAD 

Local  Area  Defense 

LAN 

Local  Area  Network 

LIS  I 

Level  of  Information  Systems  Interoperability 

LOS 

Line-Of-Sight 

MAV 

Mini  and  Micro  Unmanned  Aerial  Vehicle 

METL 

Mission  Essential  Task  List 

NIST 

National  Institute  of  Standards  and  Technology 

OJT 

On  the  Job  Training 

OJT 

On  the  Job  Training 

OTHISR 

Over-The-Hill  Intelligence  Surveillance  Reconnaissance 

OV 

Operational  View 

PSYOP 

Psychological  Operations 

QRC 

Quick  Reaction  Concept 

Recon 

Reconnaissance 

RPV 

Remotely  Piloted  Vehicle 

SAR 

Synthetic  Aperture  Radar 

SATCOM 

Satellite  Communication 

SE 

Systems  Engineering 

SEAD 

Suppression  of  Enemy  Air  Defenses 

SIGINT 

Signals  Intelligence 

SOF 

Special  Operations  Forces 

Continued  on  next  page 
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Table  A.l  -  continued  from  previous  page 


Acronym 

Description 

SoS 

Systems  of  Systems 

SPO 

System  Program  Office 

SR 

Special  Reconnaissance 

SV 

Systems  View 

TV 

Technical  Standards  View 

UAV 

Unmanned  Aerial  Vehicle 

UHF 

Ultra  High  Frequency 

UJTL 

Universal  Joint  Task  List 

US 

United  States 

USSOCOM 

United  States  Special  Operations  Command 

UW 

Unconventional  Warfare 

VHF 

Very  High  Frequency 

WAN 

Wide  Area  Network 

WMD 

Weapons  of  Mass  Destruction 

WWII 

World  War  II 
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Appendix  B.  MAV  Traceability 


Integrated  Architectures 


Figure  B.l 


Top  Level  Traceability  Diagram 
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Appendix  C.  MAV  AV-1 


AV-1:  Overview  and  Summary  Information 
ISR  MAV  (AS-IS) 

1.  Identification  Name:  Intelligence,  Surveillance  and  Reconnaissance 
Micro/Mini  Aerial  Vehicle  (AS-IS).  Short  Name:  ISR  MAV  (AS-IS)  Architecture. 
Involved  Organizations:  AFRL/MN:  Munitions  Directorate,  ISR  MAV  developer; 
AFRL/HECB:  Human  Factors  Lab,  Battlefield  Air  Operations  (BAO)  integrator; 
ASC/AAP:  Aeronautical  Enterprise  Program  Office,  System  Program  Office  (SPO); 
AFIT/ENY-GSE:  USAF  Graduate  Systems  Engineering  program,  architecture  developers. 
Date:  This  version  targets  the  FY05  timeframe.  The  period  for  the  development  of  this 
version  of  the  architecture  was  August  2004  to  March  2005. 

2.  Background:  There  currently  does  not  exist  an  integrated  architecture  that 
defines  the  use  of  the  emerging  field  of  Mini/Micro  Aerial  Vehicles  (MAV)  within  the 
Department  of  Defense,  or  the  US  Air  Force.  MAVs  are  rapidly  emerging  as  a  productive 
subset  of  the  larger  category  of  Unmanned  Aerial  Vehicles  (UAV).  They  are  loosely 
defined  by  being  small  enough  in  size  and  weight  to  be  man-packable  for  use  in  austere 
operational  environments  by  Special  Forces  Personnel.  The  MAV’s  size  and  ease  of 
testability  allows  for  rapid  development  and  modification  of  design  and  application. 

This  architecture  is  an  AS-IS  representation  of  a  generic  ISR-focused  MAV.  It  is 
based  in  large  part  on  the  design  and  operations  of  currently  operational  MAV  systems. 
There  is  a  need  for  a  baseline  architecture  in  order  to  understand  the  systems,  track 
changes  that  are  made,  and  project  forward  to  determine  capability  shortfalls  that  should 
be  addressed. 

3.  Purpose:  The  ISR  MAV  (AS-IS)  architecture  will  baseline  the  current 
capabilities  of  operational  ISR  MAVs.  The  purpose  of  this  version  of  the  architecture 
(FY05)  is  detailed  in  the  table  below. 
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4.  Scope:  The  products  associated  with  this  architecture  depict  the  AS-IS  state 
of  a  generic  ISR  MAV  system.  This  architecture  includes  the  infrastructure  and  systems 
needed  to  operate  an  ISR  MAV  by  US  military  personnel. 

5.  Time  Frame:  The  architecture  depicts  the  weapon  system  in  its  current  state 
and  certain  evolutions  expected  to  be  implemented  through  FY05.  Realistically,  the 
first  POM  cycle  that  the  completed  architecture  would  be  able  to  influence  is  FY08. 
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Table  C.l  Architecture  Purposes 


Architecture  Purpose 

Architecture  Product  Implications 

Describe  a  generic  ISR  MAV 
system  as  a  baseline  to  fully 
map  the  necessary  interfaces 
needed  to  describe  the  ISR 
MAV  mission. 

Architectural  elements  are  documented  that  are 
common  to  the  ISR  MAV  mission  and  can  be  used 
to  fully  understand  the  system’s  boundaries  and 
interfaces. 

Support  the  development 
of  an  ISR  MAV  Full  Scale 
Production  Contract  and 
serve  as  a  maintained,  author¬ 
itative  decision  making  tool 
after  contract  award 

Information  must  be  accurate  and  authoritative. 
Products  should  be  built  with  the  idea  in  mind  that  the 
future  changes  to  the  mission  profile  and  integrating 
advanced  technology  will  need  to  be  reflected  in  the 
baseline  architectures  prior  to  implementation 

Support  the  design  of  tailored 
ISR  MAV  implementations 

The  generic  architecture  should  be  extensible  to 
reflect  C2  node  or  site  specific  variations  of  ISR 
MAVs  without  losing  linkage  and  consistency  with 
the  baseline  architecture  products 

Provide  traceability  of 

requirements  to  architecture 
components 

To  be  meaningful,  the  granularity  of  the  architectural 
elements  should  be  small 

Support  the  development  of 
future  test  plans 

The  SV-1  will  provide  system  to  system  interoper¬ 
ability  requirements  while  various  other  OV/SVs  will 
aid  in  determining  system  connectivity  and  interoper¬ 
ability  requirements 

Identify  modernization 

opportunities 

Need  to  be  able  to  tag  architecture  elements  as 
being  candidates  for  replacement,  re-engineering,  or 
additional  capabilities 

Support  future  POM/APOM 
activities  by  contributing 
to  the  refinement  of  AOC 
requirements  helping  identify 
areas  for  modernization 

Requires  significant  granularity  across  a  variety  of 
OV  and  SV  products 

Be  an  integral  part  of  the 
larger  ISR  and/or  UAV 
architecture 

Use  of  same  or  interoperable  toolsets,  terminology, 
and  supporting  architecture  databases 
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Appendix  D.  MAV  OV-1 


Table  D.l  -  AY-2  Integrated  Dictionary 


Entities,  Attributes,  and 
Relationships 

Description 

Graphical  Box  Types 

Icons 

MAV 

Description:  This  icon  represents  the  aerial  vehicle 
portion  of  the  overall  MAV  system  being 
architected. 

CCT/MAV  Operator 

Description:  The  CCT/MAV  Operator  is  comprised 
of  any  person  trained  to  set  up  and  operate  a  MAV 
system.  CCT  is  shown  on  the  ISR/BDI  operational 
concept  and  MAV  operator  is  shown  on  the  Local 
Area  Defense  operational  concept.  The  CCT/MAV 
operator  is  an  integral  part  of  the  Friendly  Ground 
Unit  or  Special  Ops  Unit  described  in  the  OV-2, 
OV-6c,  and  SV-lb  views.  The  operator  either 
affects  the  system  through  direct  contact  (Platform 
Interface,  Field  Comm  Interface,  and  Hardware 
Interface)  or  through  the  HCI  system  (User 

Feedback  and  Inputs  interface). 

Type:  Operational  Node,  Activity,  or  System 

Views:  OV-1 

GPS  Satellite 

Description:  The  Global  Positioning  System 
consists  of  a  constellation  of  satellites  providing 
pseudorange  numbers  and  ephemeris  data. 

Receivers  use  this  information  to  calculate  their 
location.  The  data  provided  by  GPS  satellites  is 
required  by  MAVs  in  order  to  generate  their  current 
location  and  perform  waypoint  navigation. 

Type:  External  system 

Views:  OV-1,  OV-2,  OV-6c,  SV-lb/c 

Continued  on  next  page 
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Table  D.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

AOC 

Description:  The  AOC  is  an  external  system  that 
encompasses  any  unit  or  group  that  the  operator  is 
required  to  report  to,  or  is  considered  at  a  higher 
level  in  the  operators  chain  of  command.  This  unit 
can  be  stationed  locally  in  respect  to  the  operator 
(in  the  field)  or  remote  (far  away  from  the  operator). 
Headquarters  can  do  any  number  of  tasks,  including 
making  decisions  based  on  gathered  intelligence, 
assigning  missions  or  directives  to  field  units,  or 
providing  intelligence  information.  The  AOC  is 
synonymous  with  Local  Commanders  or 
Headquarters  on  OV-2,  OV6c,  and  SV-lb/c 
products. 

Type:  External  system 

Views:  OV-1 

COMM  Satellite 

Description:  COMM  satellites  provide  the 
CCT/operator  a  means  to  communicate  with 
decision  authorities. 

Type:  External  system  (not  shown  on  other 
products) 

Views:  OV-1 

Strike  Asset 

Description:  Strike  assets  are  external  systems  that 
are  comprised  of  any  operational  unit  that  has  the 
capability  to  inflict  damage  on  the  enemy. 

Examples  include  aircraft  (A- 10),  ground  units 
(artillery),  or  sea  based  units  (cruiser).  Strike  assets 
can  be  employed  as  a  result  of  information  obtained 
via  the  MAV  and  communicated  to  Headquarters  or 
the  local  commander. 

Type:  External  system 

Views:  OV-1,  OV-2,  SV-lb/c 

Threat 

Description:  Threats  are  any  enemy  personnel  or 
enemy  systems  that  would  interfere  with  friendly 
force  objectives. 

Type:  External  system 

Views:  OV-1 

Graphical  Arrow  Types 

Continued  on  next  page 
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Table  D.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Navigation  Data 

Description:  Depending  on  the  view,  navigation 
data  can  either  be  an  operational  needline  (OVs)  or 
an  external  interface  (SVs).  This  link  includes  the 
pseudorange  numbers  and  ephemeris  data 
transmitted  by  the  GPS  satellites. 

Type:  External  Interface  or  Needline 

Views:  OV-1,  OV-2,  OV-5,  SV-lb/c 

Data  and  Telemetry 

Description:  Data  and  Telemetry  is  the  link 
between  the  operator  and  the  aerial  part  of  the  MAV 
system  that  provides  both  sensor  data  and  necessary 
air  vehicle  information.  Data  and  Telemetry  is 
synonymous  with  Platform  Communications  on 
OV-2,  Request/Commands,  and  ISR  data  on  SV-lb, 
and  Raw  Sensor  Package  Data/Raw  Flight 

Telemetry  on  OV-5  (AO  view). 

Type:  Internal  Interface  or  Needline 

Views:  OV-1 

Comm  Link 

Description:  Comm  Links  comprise  any 
communication  link  used  by  CCTs/MAV 
operators/Friendly  Ground  Units  in  order  to  relay 
information  to  the  applicable  decision  authority  or 
strike  force  (to  include  personnel  and  aircraft)  in  the 
prosecution  of  mission  objectives.  Comm  Links  are 
synonymous  with  Communicate  with  Headquarters 
and  Communicate  with  Local  Strike  Assets  on  the 
consolidated  OV-2.  They  represent  Information 
Gathered,  Mission  Tasks  and  Intelligence  Info  and 
BDI  request,  Scheduled  Attack,  and  Enemy 

Position  on  the  SV-lb 

Type:  External  interface  or  Needline 

Views:  OV-1 
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Figure  D.l  OV-1  for  the  OTHISR  and  BDI  Scenario 
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Figure  D.2  OV-1  for  the  LAD  Scenario 
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Appendix  E.  MAV  OV-2 


Table  E.l  -  AV-2  Integrated  Dictionary 


Entities,  Attributes,  and 
Relationships 

Description 

Graphical  Box  Types: 

Operational  Nodes 

Friendly  Ground  Unit 

Description:  The  Friendly  Ground  Unit  operational 
node  includes  all  systems  that  make  up  the  ground 
piece  of  the  overall  system.  Synonymous  with  CCT, 
MAV  Operator,  or  Perform  Ground  Unit  Functions. 
Type:  Operational  Node 

Views:  OV-1,  OV-2,  OV-3,  OV-6c,  SV-lb,  SV-lc, 
SV-4 

MAV 

Description:  The  MAV  operational  node  includes 
all  systems  that  make  up  the  airborne  piece  of  the 
overall  system.  Synonymous  with  Perform  MAV 
Functions. 

Type:  Operational  Node 

Views:  OV-1,  OV-2,  OV-3,  OV-6c,  SV-lb,  SV-lc, 
SV-4 

Graphical  Box  Types: 

External  Operational  Nodes 

GPS  Satellites 

Description:  The  Global  Positioning  System 
consists  of  a  constellation  of  satellites  providing 
pseudorange  numbers  and  ephemeris  data.  Ground 
based  receivers  use  this  information  to  calculate 
their  location. 

Type:  External  Node 

Views:  OV-1,  OV-2,  OV-3,  OV-6c,  SV-lb,  SV-lc, 
SV-4,  SV-6 

Headquarters 

Description:  Headquarters  encompasses  any  unit  or 
group  that  the  operator  is  required  to  report  to,  or  is 
considered  at  a  higher  level  in  the  operators  chain 
of  command.  This  unit  can  be  stationed  locally  in 
respect  to  the  operator  (in  the  field)  or  remote  (far 
away  from  the  operator).  Headquarters  can  do  any 
number  of  tasks,  including  making  decisions  based 
on  gathered  intelligence,  assigning  missions  or 
directives  to  field  units,  or  providing  intelligence 
information.  Synonymous  with  AOC  or  Focal 
Commanders. 

Continued  on  next  page 
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Table  E.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Type:  External  Node 

Views:  OV-1,  OV-2,  OV-3,  OV-6c,  SV-lb,  SV-lc, 
SV-4,  SV-6 

Maintenance  Depot 

Description:  The  Maintenance  Depot  includes  any 
operational  unit  outside  of  the  system  that  performs 
maintenance  or  support  on  the  system.  Although 
the  diagram  only  shows  a  need  to  communicate 
with  the  Friendly  Ground  Unit  node,  the 

Maintenance  Depot  can  actually  influence  or 
perform  maintenance  on  the  entire  system 
(including  the  MAV).  The  main  purpose  of  this 
node  is  to  perform  maintenance  that  cannot  be 
performed  in  the  field  by  the  Friendly  Ground  Unit. 
Type:  External  Node 

Views:  OV-2,  OV-3,  OV-6c,  SV-lb,  SV-lc,  SV-6 

Strike  Assets 

Description:  Strike  assets  are  any  operational  unit 
that  has  the  capability  to  inflict  damage  on  the 
enemy.  Examples  include  aircraft  (A- 10),  ground 
units  (artillery),  or  sea  based  units  (cruiser). 

Type:  External  Node 

Views:  OV-1,  OV-2,  OV-3,  OV-6c,  SV-lb,  SV-lc, 
SV-4,  SV-6 

Graphical  Arrow  Types: 

Needlines 

Communicate  with 

Headquarters 

Description:  This  needline  includes  sending  ISR 
information  gathered  to  Headquarters,  and  receiving 
both  mission  tasks  and  intelligence  information 
from  Headquarters.  Synonymous  with  ‘Information 
Gathered,  Mission  Tasks,  Intelligence  Info’. 
Information  Exchange  Direction:  Bi-Directional 
Operational  Node  1:  Headquarters 

Operational  Node  2:  Friendly  Ground  Unit 

Type:  Operational  Needline 

Views:  OV-2,  OV-3,  SV-lb,  SV-lc,  SV-6 

Continued  on  next  page 
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Table  E.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Communicate  with  Local 

Strike  Assets 

Description:  Included  in  this  needline  are  BDI 
request  and  feedback  sent  from  and  to  the  Strike 
Assets.  BDI  request  include  the  type  of  strike,  last 
known  enemy  positions  (or  location  of  strike)  using 
a  standardized  coordinate  system,  and  when  the 
strike  is  scheduled  (if  not  already  occurred).  BDI 
feedback  includes  general  information  sent  back  to 
the  strike  asset  concerning  BDI  mission  results. 
Synonymous  with  ‘BDI  Request  and  Feedback’. 
Information  Exchange  Direction:  Bidirectional 
Operational  Node  1:  Strike  Assets 

Operational  Node  2:  Friendly  Ground  Unit 

Type:  Operational  Needline 

Views:  OV-2,  OV-3,  SV-lb,  SV-lc,  SV-6 

Navigation  Data 

Description:  This  needline  represents  a  need  to 
receive  navigation  data  from  GPS  Satellites.  The 
information  needed  includes  the  pseudorange 
numbers  and  ephemeris  data  which  is  transmitted 
by  the  satellites. 

Information  Exchange  Direction:  Unidirectional 
From  Operational  Node:  GPS  Satellites 

To  Operational  Node  2:  MAV 

Type:  Operational  Needline 

Views:  OV-1,  OV-2,  OV-3,  OV-5,  OV-7,  SV-lb, 
SV-lc,  SV-4,  SV-6 

Platform  Communication 

Description:  This  needline  shows  that  a  need  for 
communication  between  the  ground  (Friendly 

Ground  Unit)  and  the  airborne  (MAV)  operational 
nodes  is  required.  Such  communication  includes 
request  or  commands  to  the  MAV,  gathered  ISR 
data  sent  from  the  MAV  to  the  Friendly  Ground 

Unit,  and  a  Platform  Interface  to  allow  the  Friendly 
Ground  Unit  to  directly  interact  with  the  MAV. 
Synonymous  with  ‘Data  and  Telemetry’. 

Information  Exchange  Direction:  Bidirectional 
Operational  Node  1:  MAV 

Operational  Node  2:  Friendly  Ground  Unit 

Type:  Operational  Needline 

Continued  on  next  page 
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Table  E.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Views:  OV-1,  OV-2,  OV-3 

System  Maintenance 
Needed/Request 

Description:  This  needline  shows  that  there  is  a 
need  for  communication  between  the  Maintenance 
Depot  and  the  Friendly  Ground  Unit  nodes. 

Included  here  is  the  Friendly  Ground  Units  request 
for  maintenance  to  be  performed  on  the  system  and 
the  Maintenance  Depots  acknowledgement  of 
completed  maintenance.  Such  maintenance 
requests  occur  whenever  the  Friendly  Ground  Unit 
is  not  capable  or  it  is  out  of  the  scope  of  field  level 
maintenance. 

Information  Exchange  Direction:  Bidirectional 
Operational  Node  1:  Maintenance  Depot 

Operational  Node  2:  Friendly  Ground  Unit 

Type:  Operational  Needline 

Views:  OV-2 

Relationships 

Operational  Node 

Organization  Type 

Friendly  Ground  Unit 

Any  size  land  based  force  (personnel  and 
equipment) 

MAV 

ISR  Gathering  and  Disseminating 

Operational  Node 

Operational  Activity 

Friendly  Ground  Unit 

Process  Information  (All),  Provides  Vehicle 

Control  and  Communication  (A  12),  Initialize  MAV 
(A21),  Calibrate  MAV  (A22),  Upload  Mission 

Profile  (A23),  Faunch  MAV  (A24),  Recover  MAV 
(A44),  Provide  Field  Fevel  Maintenance  (A5) 

MAV 

Provides  Flight  Controls  (A31),  Provides  Flight 
Vehicle  (A32),  Enables  Sensor  Package  (A33), 
Calculate  Flight  Plan  to  Fanding  Zone  (A41),  Fly  to 
Fanding  Zone  (A42),  Perform  Fanding  Sequence 
(A43) 
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Figure  E.l  Consolidated  OV-2 
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Appendix  F.  MAV  OV-3 

As  mentioned  in  Section  3.2.3,  the  OV-3  matrix,  as  with  any  defined  matrix,  is  a  set  of 
rows  and  columns  where  their  intersections  contain  information.  The  rows  contain  all 
information  contained  within  a  particular  information  exchange.  Since  the  relationship 
between  needlines  and  exchanges  are  one-to-many  they  are  categorized  first  by  the 
operational  needline  shown  in  the  OV-2  and  then  by  the  information  exchange  identifiers 
which  are  OV-3  unique.  The  columns  show  specific  information  based  on  the  columns 
heading.  Many  times,  the  column  headings  are  tailored  to  the  specific  system  type  that 
is  being  modeled.  A  template  for  a  highly  complex,  secure,  and  detailed  communication 
system  may  have  many  extraneous  columns  for  a  simpler  system  with  few  information 
exchanges.  The  tailored  list  below  is  the  column  headings  with  their  meanings  as  defined 
by  DoDAF  [24].  The  columns  outside  the  scope  of  this  initial  baseline  architecture  have 
been  marked  Left  Blank.  This  research  will  still  show  these  empty  columns  in  order  to 
allow  for  future  detailed  research.  Following  the  column  definitions  are  the  OV-3  matrix 
figures  completed  for  the  Baseline  ISR  MAV. 


Row  ID:  Contains  a  unique  row  number  for  each  row  and  is  used  for  easier 
referencing  (instead  of  having  to  recite  the  information  exchange  identifier). 

Needline  Identifier:  Identifies  the  needline  as  shown  in  the  OV-2  operational  node 
connectivity  diagram  that  carries  the  information  exchange. 

Information  Exchange  Identifier:  Identifies  the  information  exchange,  based  on 
and  contained  within  an  operational  needline,  and  is  unique  to  the  OV-3  matrix. 

Information  Element  Name:  Shows  the  corresponding  information  element,  as 
shown  in  the  OV-7,  for  the  information  exchange.  This  column  can  also  include 
the  information  flow  from  the  OV-5  if  the  OV-7  is  not  available  or  does  not  go  into 
sufficient  depth.  For  this  research  this  column  is  based  on  information  flows  from 
the  OV-5. 
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Content:  Content  of  the  information  element,  meaning  the  actual  information  to  be 
exchanged. 

Scope:  Description  of  the  extent  or  range  of  the  information  element  content. 

Accuracy:  Degree  to  which  the  information  conforms  to  actual  fact  as  required  by 
the  operational  node. 

Language:  Identifies  the  codes  or  natural  languages  involved  in  the  information 
exchange  (multinational).  Left  Blank 

Sending  Op  Node  Name:  Name  of  the  operational  node  from  the  OV-2  that 
produces  the  information. 

Sending  Op  Activity  Name  and  ID:  Name  and  identifier  of  the  operational  activity 
from  the  OV-5  producing  the  information. 

Receiving  Op  Node  Name:  Name  of  the  operational  node  from  the  OV-2  that 
consumes  the  information. 

Receiving  Op  Activity  Name  and  ID:  Name  and  identifier  of  the  operational 
activity  from  the  OV-5  consuming  the  information. 

Mission/Scenario,  UJTL,  METL,  or  AFTL:  Joint  Mission  Area,  cross-mission 
area  domain,  Univeral  Joint  Task  List  (UJTL)  activity,  related  specific  scenario,  Air 
Force  Task  List  (AFTL),  or  other  mission/scenario  task-related  publication.  For  this 
research  the  AFTL  were  used  as  outlined  earlier  in  the  traceability  section  (4.2). 

Transaction  Type:  Contains  the  type  of  exchange  (in  high-level  terms). 

Triggering  Event:  Textual  description  of  the  event(s)  shown  in  the  OV-6C  that 
triggers  the  information  exchange.  If  triggering  events  are  not  included  in  the 
OV-6C  then  this  column  is  not  required  however  an  example  of  such  a  event  can  be 
given  as  the  case  with  this  research. 

Interoperability  Level  Required  (from  C4ISR  WG):  Level  of  Information 
Systems  Interoperability  (LISI),  or  other  interoperability  measure.  This  research 
used  the  C4ISR  Working  Groups  [10]  interoperability  levels.  There  are  5  possible 
levels  of  interoperability  an  information  exchange  can  have,  numbered  0  to  4.  Level 
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0  is  termed  the  Isolated  Level  and  consists  of  manual  access  control  procedures, 
manual  infrastructure  and  private  data.  Level  1  is  termed  the  Connected  Level 
and  consists  of  a  security  profile,  two  or  one  way  infrastructure,  and  basic  data 
formats.  Level  2  is  termed  the  Functional  Level  and  consists  of  a  common  operating 
environment,  a  local  area  network  (LAN)  infrastructure,  program  models,  and 
advanced  data  formats.  Level  3  is  termed  the  Domain  Level  and  consists  of 
domain  procedures,  a  wide  area  network  (WAN),  database  management  system 
(DBMS),  and  domain  models.  Level  4  consists  of  enterprise  procedures  (DoD, 
Multi-National),  multiple  dimensional  topologies,  and  cross  enterprise  models. 

Criticality:  The  criticality  assessment  of  the  information  being  exchanged  in 
relationship  of  the  mission  being  performed,  meaning  how  essential  is  it  to  the 
overall  mission  or  capability. 

Periodicity:  How  often  the  information  exchange  occurs;  may  be  an  average  or 
worst  case  estimate  and  can  include  conditions. 

Timeliness:  Required  maximum  allowable  time  of  exchange  from  node  to  node. 
This  research  uses  in  minutes  and  in  seconds  to  state  the  order  of  measurement  to 
be  used  for  the  information  exchange. 

Access  Control:  The  class  of  mechanisms  used  to  ensure  only  those  authorized 
can  access  information.  Left  Blank 

Availability:  The  relative  level  of  effort  required  to  be  expended  to  ensure  that  the 
information  can  be  accessed.  Left  Blank 

Confidentiality:  The  kind  of  protection  required  for  information  to  prevent 
unintended  disclosure.  Left  Blank 

Dissemination  Control:  The  kind  of  restrictions  on  receivers  of  the  information 
based  on  sensitivity  of  information.  Left  Blank 

Integrity:  The  kind  of  requirements  for  checks  that  the  content  of  the  information 
has  not  been  altered.  Left  Blank 

Accountability:  Security  principle  that  ensures  that  responsibility  for 

actions/events  can  be  given  to  an  organization  willingly  or  by  obligation. 
Left  Blank 
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Protection  (Type,  Name,  Duration):  Name  for  the  type  of  protection  and  how 
long  the  information  must  be  safeguarded.  Left  Blank 

Classification:  Classification  code  for  the  information.  Left  Blank 

Classification  Caveat:  A  set  of  restrictions  on  information  of  a  specific  classifi¬ 
cation;  supplements  a  security  classification  with  information  on  access,  dissemi¬ 
nation,  and  other  types  of  restrictions.  Left  Blank 
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Appendix  G.  MAV  OV-4 


Table  G.l  -  AY-2  Integrated  Dictionary 


Entities,  Attributes,  and 
Relationships 

Description 

Graphical  Box  Types: 

Organizations 

AF  Materiel  Command 

Description:  This  is  the  overarching  acquisition  and 
development  command  for  the  two  main 
organizations,  AF  research  labs  and  the  UAV 
system  program  office.  While  there  may  be  more 
levels  of  command  between  this  organization  and 
AFMC,  it  is  represented  here  to  show  its 
comparison  to  the  AF  Special  Operations 

Command  level.  It  is  responsible  for  the  cradle  to 
grave  management  of  the  MAV  system 
(development,  acquisition,  sustainment,  tech 
support,  and  retirement  of  the  system). 

Type  of  Organization:  Command  Level 

Organization 

Views:  OV-4 

AF  Special  Operations 
Command 

Description:  This  is  the  overarching  special 
operations  command  that  controls  the  user  for  this 
system.  Other  commands  may  also  have  users  of 
the  system  (i.e.  Air  Combat  Command),  however, 
for  this  view,  AFSOC  will  represent  any  and  all 
users  of  the  system.  It  is  responsible  for  training, 
supporting,  and  directing  its  materiel  towards  the 
goals  of  the  combatant  commanders  in  the  realm  of 
special  operations. 

Type  of  Organization:  Command  Level 

Organization 

Views:  OV-4 

AF  Research  Lab  or  Munitions 
Directorate 

Description:  This  organization  is  in  directorate 
level  control  of  the  developing  offices  and  teams  of 
the  MAV.  It  is  states  as  either  an  AF  Research  Lab 
or  Munitions  Directorate  because  the  intuitive 
choice  of  an  AF  Research  Lab  is  not  the  only 
possible  case.  It  is  responsible  for  managing  its 
programs  and  offices  within  its  given  budget, 
constraints  and  directives  toward  the  goals  of 
developing  new  and  emerging  technology. 

Continued  on  next  page 
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Table  G.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Type  of  Organization:  Directorate  Level 

Organization 

Views:  OV-4 

UAV  System  Program  Office 

Description:  This  organization  is  either  a  dedicated 
System  Program  Office  (SPO)  for  Unmanned  Aerial 
Vehicles  (UAV)  or  is  the  Basket  SPO  that  would 
control  the  MAV  system.  It  is  responsible  for  the 
Operational  Safety,  Suitability,  and  Effectiveness 
(OSS&E)  of  all  UAV  systems  under  its  control. 

Type  of  Organization:  Directorate  Level 

Organization 

Views:  OV-4 

MAV  Lab 

Description:  This  organization  is  responsible  for  the 
actual  development  of  the  MAV  system  and  its 
capabilities.  After  technology  development  and 
demonstration,  it  will  transition  it  to  the  MAV  SPO. 

It  is  responsible  for  the  Operational  Safety, 
Suitability,  and  Effectiveness  (OSS&E)  of  the  MAV 
system. 

Type  of  Organization:  Division  Level  Organization 
Views:  OV-4 

MAV  System  Program  Office 

Description:  This  organization  is  responsible  for  the 
Operational  Safety,  Suitability,  and  Effectiveness 
(OSS&E)  of  the  MAV  system.  It  is  the  single  face 
to  the  user  that  handles  new  acquisition  of  the 
system,  its  parts,  any  technical  support  issues  from 
the  user,  modifications,  and  maintenance  plans/ 
directives  on  the  system. 

Type  of  Organization:  Directorate  or  Division  Level 
Organization 

Views:  OV-4 

Mission  Support 

Description:  This  organization  is  responsible  for 
training,  equipping,  and  supporting  the  special 
operation  forces  to  enable  them  to  perform  their 
missions.  They  will  maintain  the  MAV  systems, 
beyond  field  repair  requirements.  They  will  act  as 
the  user  representative  to  the  SPO  on  any  technical 
issues  regarding  the  MAV  inventory. 

Continued  on  next  page 
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Table  G.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Type  of  Organization:  Directorate  Level 

Organization 

Views:  OV-4 

Operations 

Description:  This  organization  is  responsible  for 
directing  the  special  operations  forces  in 
completing  their  missions.  Its  main  responsibility  is 
to  execute  their  directed  missions  from  the 
combatant  commanders.  This  organization  is 
represented  as  the  Local  Commander/  Headquarters 
on  the  OV-2  diagram. 

Type  of  Organization:  Directorate  Level 

Organization 

Views:  OV-4 

Engineering 

Description:  This  organization  is  responsible  for  the 
technical  aspects  of  the  system.  In  the  MAV  Lab 
hierarchy  it  is  responsible  for  the  research,  design, 
integration,  and  test  of  the  system.  In  the  SPO 
hierarchy  it  is  responsible  for  the  technical  orders, 
modifications,  and  technical  issues  related  to  the 
MAV.  It  will  likely  have  a  chief  engineering  who 
will  be  the  primary  advisor  the  parent  organizations 
chief  officer  on  any  OSS&E  issues. 

Type  of  Organization:  Branch  Level  Organization 
Views:  OV-4 

Program  Management 

Description:  This  organization  is  responsible  for  all 
management  aspects  of  the  system.  In  both  the 

MAV  Lab  and  SPO  this  organization  manages 
planning,  programming,  and  budgeting  of  the 
system.  It  also  manages  the  acquisition  cycle 
aspects  of  the  system. 

Type  of  Organization:  Branch  Level  Organization 
Views:  OV-4 

Continued  on  next  page 
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Table  G.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Flight  Systems 

Description:  This  organization  is  responsible  for  the 
MAV  flight  systems.  Specifically  it  is  responsible 
for  the  aircraft  portion  of  the  system.  In  the  MAV 

Lab  this  organization  develops  and  demonstrates 
designs  for  the  aircraft.  In  the  SPO  this  organization 
handles  any  issues  related  to  the  fielded  aircraft 
(T.O.  changes,  field  questions,  modifications). 

Type  of  Organization:  Section  Level  Organization 
Views:  OV-4 

Ground  Systems 

Description:  This  organization  is  responsible  for  the 
MAV  ground  systems.  Specifically  it  is  responsible 
for  the  portion  of  the  system  that  remains  on  the 
ground  during  operation.  In  the  MAV  Lab  this 
organization  develops  and  demonstrates  designs  for 
the  ground  systems.  In  the  SPO  this  organization 
handles  any  issues  related  to  the  fielded  ground 
system  (T.O.  changes,  field  questions, 
modifications). 

Type  of  Organization:  Section  Level  Organization 
Views:  OV-4 

Sensor  Systems 

Description:  This  organization  is  responsible  for  the 
MAV  sensor  systems.  Specifically  it  is  responsible 
for  the  various  sensor  capabilities  used  by  the  MAV 
system.  In  the  MAV  Lab  this  organization  develops 
and  demonstrates  designs  for  various  sensors.  In  the 
SPO  this  organization  handles  any  issues  related  to 
the  fielded  sensors  (T.O.  changes,  field  questions, 
modifications). 

Type  of  Organization:  Section  Level  Organization 
Views:  OV-4 

Continued  on  next  page 
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Table  G.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Integration  Section 

Description:  This  organization  works  with  the 
members  of  the  flight  systems,  ground  system,  and 
sensor  systems  sections  to  produce  an  integrated, 
testable  design  for  demonstration.  This 
organization  likely  relies  on  system  engineering 
principles  and  products.  As  an  alternative  to  this 
organization,  an  integrated  team  of  the  mentioned 
sections  with  a  single  human  role  of  systems 
engineer  could  potentially  serve  the  same  function. 
Type  of  Organization:  Section  Level  Organization 
Views:  OV-4 

Test  Section 

Description:  This  organization  works  with  all  of  the 
sections  to  test  and  evaluate  a  full  MAV  design  for 
technology  demonstration.  Following  successful 
test  and  evaluation,  the  designs  may  or  may  not  be 
transitioned  to  the  SPO  for  full  system  production. 
Type  of  Organization:  Section  Level  Organization 
Views:  OV-4 

Research  Section 

Description:  This  organization  is  responsible  for 
research  related  to  new  or  emerging  technology 
related  to  the  MAV  system.  It  works  to  integrate 
findings  from  that  research  into  actionable 
technology  for  use  by  the  other  sections. 

Type  of  Organization:  Section  Level  Organization 
Views:  OV-4 

Academic  Institutions 

Description:  These  organizations  operate  under 
research  grants  to  develop  new  and  emerging 
technology  as  directed  through  the  research  section 
of  the  MAV  lab.  Their  findings  are  then  transitioned 
into  useful  technology  for  inclusion  in  MAV  system 
design. 

Type  of  Organization:  Consultant  Organization 
Views:  OV-4 

Continued  on  next  page 
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Table  G.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Contractor  Support 

Description:  This  organization  can  be  of  any  size  or 
level.  It  is  responsible  for  performing  its  contractual 
obligations  to  the  government  in  support  of  the 
office  it  has  been  contracted  to.  Various  contracts 
can  be  performed.  Research  contracts  with  the 

MAV  Lab  seek  to  develop  technology  or  integrate 
existing  designs  to  produce  initial  design  units  for 
demonstration.  Production  contracts  with  the  SPO 
seek  to  simply  produce  already  designed  systems 
for  fielding. 

Type  of  Organization:  Consultant  Organization 
Views:  OV-4 

Logistics  Management 

Description:  This  organization  is  responsible  for  the 
logistical  support  required  to  keep  the  MAV 
systems  in  inventory  operational.  It  acquires, 
maintains,  and  distributes  parts  as  needed  to  keep 
the  MAVs  operational. 

Type  of  Organization:  Branch  Level  Organization 
Views:  OV-4 

Field  Teams 

Description:  These  organizations  are  the  actual 
operators  of  the  MAV  System.  They  are  organized 
by  mission,  but  typically  are  between  1  and  10 
members.  They  combine  with  the  ground  system  of 
the  MAV  to  represent  the  Friendly  Ground  Unit  as 
displayed  in  the  OV-2  diagram. 

Type  of  Organization:  Section  Level 

Views:  OV-4 

Development  Team 

Description:  This  organization  is  the  combined 
team  of  all  member  organizations  required  to 
develop  the  MAV  system.  It  includes  all  members 
of  the  MAV  lab  as  well  as  representation  from  the 
Academic  Institution  and  Contractor  Support. 

Type  of  Organization:  Integrated  Team 

Views:  OV-4 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

SPO  Team 

Description:  This  organization  is  the  combined 
team  of  all  member  organizations  required  to 
perform  the  role  of  SPO  for  the  MAV  system.  It 
includes  all  members  of  the  MAV  SPO  as  well  as 
representation  from  Contractor  Support. 

Type  of  Organization:  Integrated  Team 

Views:  OV-4 

Graphical  Arrow  Types: 

Organizational  Relationships 

Command  Relationships 

Description:  These  relationships  are  represented  by 
solid  lines  connecting  organizations.  They  represent 
command  between  the  higher  organization  and  its 
sub-organizations.  It  implies  reporting 
responsibility,  budgetary  roll-up,  and  other 
considerations  regarding  a  chain  of  command. 

Type:  Hierarchical 

Technology  Transition  /  Spiral 
Feedback 

Description:  This  relationship  represents  the  MAV 
Lab  in  general  transitions  the  technology  to  the 

MAV  SPO.  It  also  represents  that  in  general  the 

MAV  SPO  will  provide  feedback  for  future  spirals 
of  the  existing  design  to  help  focus  efforts  of  the 
MAV  Lab. 

Type:  General  Responsibilities 

Organizations:  MAV  Lab  and  MAV  SPO 

Sustainment  /  Spiral  Feedback 

Description:  This  relationship  represents  the  MAV 
SPO  in  general  is  responsible  for  sustaining  the 

MAV  system  to  the  Mission  Support.  In  return, 
Mission  Support  will  provide  feedback  to  the  MAV 
SPO  for  future  design  spirals. 

Type:  General  Responsibilities 

Organizations:  MAV  SPO  and  Mission  Support 

Program  Interface 

Description:  The  relationship  shows  the 
communication  link  between  the  two  program 
management  organizations.  While  there  will  likely 
be  more  inter-sectional  communication  between  the 
MAV  Lab  and  the  MAV  SPO,  the  Program 
Management  organizations  will  have  an  formal 
communication  regarding  documented  milestones, 
requirements,  etc. 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Type:  Communication 

Organizations:  Program  Management  (MAV  Lab) 
and  Program  Management  (MAV  SPO) 

Research  Contracts 

Description:  This  relationship  represents  the 
contractual  responsibility  of  the  Contractor  Support 
to  the  Program  Management  (MAV  Lab)  to  work 
on  a  research  related  contract. 

Type:  Under  Contract 

Organizations:  Program  Management  (MAV  Lab) 
and  Contractor  Support 

Research  Grants 

Description:  This  relationship  represents  the 
contractual  responsibility  of  the  Academic 

Institution  to  the  Research  Section  to  work  under  a 
research  grant. 

Type:  Under  Contract 

Organizations:  Research  Section  and  Academic 
Institutions 

Production  Contracts 

Description:  This  relationship  represents  the 
contractual  responsibility  of  the  Contractor  Support 
to  the  Program  Management  (MAV  SPO)  to  work 
on  a  production  related  contract. 

Type:  Under  Contract 

Organizations:  Program  Management  (MAV  SPO) 
and  Contractor  Support 

Tech  Support 

Description:  This  relationship  is  the  act  of  the 
operators  working  through  Mission  Support  to 
request  clarification  on  issues  regarding  the  MAV 
system.  Mission  Support  would  use  this 
communication  to  seek  help  on  T.O.  questions, 
maintenance  deviations,  etc. 

Type:  Communication 

Organizations:  SPO  Team  and  Mission  Support 

Supply  /  Equip 

Description:  This  relationship  is  the  act  of  the 
Mission  Support  Organization  providing 
operationally  ready  MAV  systems  to  the  operators 
and  re- supplying  or  repairing  those  systems  as 
needed. 

Type:  Physical  Interface 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Organizations:  Mission  Support  and  Field  Teams 
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Baseline  ISR  MAV 

OV-4  Organizational  Relationships  Chart 


Figure  G.  1  OV-4  Organizational  Relationships  Diagram 
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Development  Team 


Appendix  H.  MAV  OV-5 


Table  H.l  -  Functional  Entities 


Data  Elements 

Example  Values/Explanation 

Graphical  Box 
Types 

ID 

Calibrate  MAV 

(Block  A22) 

Set  home  position  for  MAV  and  ensure  all  onboard 
navigation  systems  are  getting  or  sending  correct 
information. 

Enable 

Land/Recover 

MAV 

(Block  A4) 

Similar  to  Enable  Launch  MAV  where  the  system 
receives  the  updated  mission  profile,  flies  to  the 
landing  zone  and  performs  the  landing  sequence. 
The  last  action  is  by  the  user  when  the  MAV  is 
physically  picked  up  and  inspected  for  damage 
before  returning  to  service. 

Enable  Launch 

MAV 

(Block  A2) 

All  activities  pertaining  to  providing  the  MAV 
with  a  mission  and  setting  it  on  that  mission.  This 
includes  the  functions  of  initialization  by  the 
operator,  calibrating  the  navigation  systems, 
uploading  the  mission,  and  physically  launching 
the  MAV. 

Enables  Sensor 
Package 

(Block  A33) 

Ensures  that  the  desired  sensor  packages  can  be 
carried  onboard.  This  refers  mainly  to  fuselage 
space,  cooling,  powering  the  sensor,  etc. 

Fly  to  Landing 
Zone 

(Block  A42) 

The  MAV  will  fly  to  the  landing  zone  directed  by 
the  landing  instructions. 

Initialize  MAV 

(Block  A21) 

Power  on  the  MAV  and  make  sure  all  connections 
are  functioning. 

Launch  MAV 

(Block  A24) 

Power  on  the  propulsion  system  and  physically 
throw  the  MAV. 

Process 

Information 

(Block  All) 

Refers  to  both  the  hardware  processing  via  laptop 
or  other  device  as  well  as  the  human  user  making 
decisions  based  on  the  gathered  information 

Provide 

Command  and 
Control 

(Block  A-2) 

The  function  performed  by  headquarters  or  similar 
official  body. 

Continued  on  next  page 
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Table  H.l  -  continued  from  previous  page 


Graphical  Box 
Types 

ID 

Provide  Field 
Level 

Maintenance 

(Block  A5) 

This  encompasses  any  held  level  repairs  done  to 
the  MAV  either  before  or  after  the  mission 
including,  but  not  limited  to:  changing  batteries, 
changing/repairing  wings,  swapping  out  sensor 
packages,  changing/repair  propellers,  etc. 

Provide  GPS 
System 

(Block  A-l) 

The  navigation  data  coming  from  the  GPS 
satellites. 

Provide  ISR 
Capabilities 

(Block  AO) 

The  main  purpose  of  the  system  is  to  provide  an 
extension  to  the  tools  the  SOF  teams  already 
employ  in  the  held. 

Provide  Non 

Field-Level 

Maintenance 

(Block  A-3) 

Any  maintenance  on  the  MAV  which  cannot  be 
performed  in  the  held,  i.e.  repairing  the  fuselage  or 
sensor  packages. 

Provide  Strike 

Assets 

(Block  A-4) 

The  information  provided  by  the  MAV  will  be 
used  to  direct  strike  missions  by  the  strike  assets. 

Provides  Flight 
Controls 

(Block  A31) 

Autopilot  and  ah  relevant  sensor  hardware 
required  for  autonomous  or  remotely  piloted 
control  of  the  MAV. 

Provides  Flight 
Vehicle 

(Block  A32) 

Refers  to  the  physical  air  platform  which  is 
capable  of  carrying  the  sensor  package,  navigation 
systems,  propulsion  and  batteries  necessary  for 
mission  execution. 

Provides  ISR 

MAV  Platform 

(Block  A3) 

The  other  main  function  of  this  system  is  to 
provide  a  usable  MAV  considering  form,  fit  and 
function  as  it  relates  to  carriage  and  operation  in  a 
mission  scenario. 

Provides  Vehicle 
Control  and 
Communication 

(Block  A 12) 

This  can  be  considered  to  be  the  functions 
provided  by  the  ground  station  radio.  The  data 
from  the  MAV  is  decoded  and  sent  to  the  users 
computer  or  display  from  here.  Also,  the  flight 
plan  is  sent  from  the  users  input  system  to  the 

MAV  via  the  hardware  and  communication 
methods  designed  into  the  system. 

Recover  MAV 

(Block  A44) 

The  user  physically  picks  up  the  MAV  and  inspects 
it  for  damage. 

Upload  Mission 
Profile 

(Block  A23) 

The  operator  sends  the  desired  mission  profile  to 
the  MAV. 
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Table  H.2  -  Activity  Diagram  ICOMs 


Data 

Elements 

Example  Values/Explanation 

Graphical 
Arrow  Types 

Origin 

Destination 

Actuator 

Commands 

A31 

A3  2 

The  communication  between  the  flight 
control  computer/autopilot  system  and  the 
actuators  or  servos. 

Airframe 

Fault 

A3 

A5 

Generic  error  reported  to  the  user 
comprising  of  any  or  ah  of  the  following: 
flight  control  fault,  flight  vehicle  fault,  and 
sensor  package  fault. 

Calibration 

Fault 

A22 

A5 

This  fault  consists  of  the  navigation  system 
being  unable  to  acquire  sufficient  satellite 
coverage  to  determine  its  current  position. 
The  fault  can  also  refer  to  a  failure  of  the 
relative  positional  sensors  or  a  failure  of 
the  flight  control  system. 

Decoded 

Flight 

Telemetry 

A12 

A12 

The  flight  telemetry  data  after  it  passes 
through  the  ground  communication  suite. 

Decoded 

Sensor 

Package  Data 

A12 

All 

The  sensor  package  data  after  it  passes 
through  the  ground  communication  suite. 

Flight  Control 
Fault 

A31 

A5 

A  failure  in  the  flight  control  system. 
Includes  failures  of  flight  control  computer, 
servos  or  attachments  to  flight  control 
surfaces. 

Flight  Control 
Feedback 

A32 

A31 

Feedback  from  the  flight  path  monitoring 
hardware  (i.e.  gyros,  accelerometers,  GPS 
receiver)  to  the  navigation  computer. 

Flight  Fault 

A41 

A5 

Refers  to  any  error  encountered  after  the 
landing  zone  coordinates  are  given  to  the 
MAV. 

Flight  Plan 

All 

A12 

The  waypoints  or  mission  profile  sent  from 
the  user  to  the  autopilot. 

Flight  Rules 
or  Airspace 
Deconfliction 

N/A 

A1 

Any  external  limitations  such  as  weather, 
terrain  or  the  local  airspace  condition 
which  would  affect  the  usage  or  flight  plan 
of  the  system. 

Continued  on  next  page 
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Graphical 
Arrow  Types 

Origin 

Destination 

Flight  Vehicle 
Fault 

A32 

A5 

Failure  in  the  structure  of  the  flight  vehicle. 
Can  result  from  impact  with  foreign 
airborne  objects  or  material  /  construction 
defects  of  the  MAV. 

Fused  Target 
Information 

All 

A-2 

The  processed  information  gathered  from 
the  MAV  and  sent  back  to  headquarters  or 
decision  making  authority  for  further 
processing  or  action. 

Fused  Target 
Information 

All 

A-4 

Any  processed  information  requiring 
action  from  a  strike  asset. 

Ground 

Station 

N/A 

AO  Tunneled 

The  communication  hardware  necessary  to 
send  and  receive  all  pertinent  information 
as  well  as  the  required  hardware  to  display 
the  information  to  the  user. 

Ground 

Station  Fault 

A12 

A5 

Any  equipment  failure  resulting  in  the 
inability  of  the  operator  to  receive,  transmit 
or  interpret  information  coming  to  or  from 
the  MAV.  This  includes  failures  in  the 
display  device,  the  radio  equipment  or 
ground  based  wiring  or  requisite  batteries. 

Human 

Operator 

N/A 

AO  Tunneled 

The  human  user  of  the  system  responsible 
for  system  use  and  repair. 

Initialization 

Fault 

A21 

A5 

Failure  of  the  onboard  power  systems  or 
other  inability  to  pass  built-in  internal  test. 

Land 

Decision 

A12 

A41 

Either  a  user  directed  landing  or  mission 
completion  resulting  in  the  need  to  land. 

Landing  Fault 

A4 

A5 

Generic  error  comprising  of  either  a  flight 
fault  or  a  recovery  fault. 

Launch 

Decision 

A12 

A21 

The  decision  to  launch  the  MAV. 

Launch  Fault 

A24 

A5 

Any  post  upload  failure  resulting  in  the 
MAVs  inability  to  perform  the  mission. 

This  is  most  likely  an  operator  launch  error 
due  to  environmental  conditions. 

MAY  Landed 

A41 

A42 

MAV  arrives  at  the  landing  zone  and  the 
airspeed  is  zero. 

Continued  on  next  page 
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Graphical 
Arrow  Types 

Origin 

Destination 

MAV  Launch 

Fault 

A2 

A5 

Any  failure  resulting  from  the  onboard 
systems  inability  to  power  on,  be  calibrated 
or  to  upload  the  mission  profile. 

Mission 

Operable 

Recovery 

A42 

All 

The  desired  state  for  the  MAV.  It  has 
performed  the  mission,  has  landed  and  is 
prepared  to  be  launched  again. 

Mission 

Operating 

Procedures 

N/A 

AO  Tunneled 

Any  specific  flight  or  usage  restrictions 
imposed  by  the  particular  mission. 

Navigation 

Data 

A-l 

A31 

GPS  signal  or  inertial  data  required  for  the 
autopilot  and  user  to  know  where  the  MAV 
is  and  where  it  is  headed. 

Operational 

MAVs 

A-3 

AO  Tunneled 

These  are  either  resupply  or  repaired 

MAVs  coming  from  the  non-field  level 

MAV  repair  site. 

Power  On 

A21 

A22 

All  systems  have  power  and  are  prepared 
for  calibration. 

Raw  Flight 
Telemetry 

Data 

A31 

A12 

Airborne  communication  feedback  coming 
from  the  guidance  system  on  the  MAV  to 
the  ground  station  communication  gear. 

Raw  Sensor 
Package  Data 

A33 

A12 

Airborne  communication  which  sends  the 
data  from  the  sensor(s)  onboard  the  MAV 
to  the  ground  station  communication  gear. 

Recovery 

Fault 

A42 

A5 

Any  fault  making  the  MAV  unrecoverable. 
The  main  source  of  this  error  would  be 
controlled  flight  into  terrain  or  impact  with 
foreign  airborne  object  on-route  to  the 
landing  zone. 

Repairs 

Required 

A5 

A-3 

Systems  identified  as  needed  repairs  which 
cannot  be  performed  in  the  field. 

Sensor 

Package  Fault 

A33 

A5 

Any  fault  resulting  the  in  the  inability  of 
the  sensor  package  to  perform  its  purpose. 

Successful 

Calibration 

A22 

A23 

All  flight  required  systems  have  been 
successfully  calibrated. 

Successful 

Launch 

A24 

A31 

MAV  is  carrying  out  the  uploaded  mission. 

Continued  on  next  page 
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Graphical 
Arrow  Types 

Origin 

Destination 

Successful 

Upload 

A23 

A24 

The  mission  profile  was  successfully 
received  and  interpreted  by  the  navigation 
computer. 

System 

Repair  Status 

A5 

All 

The  status  of  the  system  after  some  fault 
has  been  generated  in  the  system.  This 
information  goes  back  to  the  user  for 
operational  impact  determination. 

Tasking 

A-2 

All 

Refers  either  to  an  internally  or  externally 
generated  need  for  intelligence  resulting  in 
deployment  of  the  MAV  system. 

Upload  Fault 

A23 

A5 

Any  fault  resulting  in  failure  of  the  mission 
profile  to  be  properly  received  or 
interpreted  by  the  navigation  computer. 

User 

Commands 

A12 

A21 

The  operator  readies  the  MAV  for  launch 
and  turns  on  power  to  the  onboard  systems. 

User 

Commands 

A12 

A22 

Instructions  sent  to  the  MAV  which 
calibrate  the  navigation  system  and/or  the 
onboard  sensor  package. 

User 

Commands 

A12 

A23 

The  user  sends  the  autonomous  mission 
profile  to  the  navigation  computer 
consisting  of  waypoints,  altitudes, 
climb/dive  parameters,  etc. 

User 

Commands 

A12 

A24 

Consists  of  physically  launching  the 
system  into  the  air. 

User 

Commands 

A12 

A31 

The  user  can  manually  control  the  flight 
path  of  the  plane  within  control  surface 
limitations. 

User 

Commands 

A12 

A33 

Provision  allowing  the  user  to  either 
activate  or  deactivate  the  sensor  package 
while  in  flight. 

User 

Commands 

A12 

A41 

Updating  the  mission  profile  with  the 
landing  zone  coordinates  and  desired  flight 
path  to  that  landing  zone. 
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Baseline  ISR  MAV 

Operational  Activity  Model  OV-5 
External  Systems  Diagram  A-1 


Figure  H.l  OV-5  External  System  Diagram 
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Purpose:  To  provide  ground  forces  with  a  single-man 
packable,  single-man  operable  ISR  capability. 
Viewpoint:  Operator 


Baseline  ISR  MAV 

Operational  Activity  Model  OV-5 


Figure  H.2  OV-5  Context  Diagram 
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Purpose:  To  provide  ground  forces  with  a  single-man 
packable,  single-man  operable  ISR  capability. 
Viewpoint:  Operator 


Baseline  ISR  MAV 

Operational  Activity  Model  OV-5 
AO  Diagram 


Figure  H.3  OV-5  Initial  Decomposition 
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Baseline  ISR  MAV 

Operational  Activity  Model  OV-5 
A 1  Diagram 
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Raw  Flight  Telemetry  Data - ►  A12  —  Decoded  sensor 

Package  Data 


Figure  H.5  OV-5  Enable  Launch  MAY 
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Baseline  ISR  MAV 


Figure  H.6  OV-5  Provide  ISR  MAV  Platform 
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Figure  H.7  OV-5  Enable  Land/Recover  MAY 
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Appendix  I.  MAV  0V-6c 


Table  1.1  -  AY-2  Integrated  Dictionary 


Entities,  Attributes,  and 
Relationships 

Description 

Graphical  Box  Types: 

Swimlane/Operational  Node 

Friendly  Ground  Unit 

Description:  See  OV-2  Operational  Node 

Description  Concept  Graphics. 

Type:  Swimlane/  Operational  Node 

Views:  OV-1,  OV-2,  OV-5,  OV-6c,  SV-lb 

MAV 

Description:  See  OV-1  High-Level  Operational 
Concept  Graphics. 

Type:  Swimlane/  Operational  Node 

Views:  OV-1,  OV-2,  OV-5,  OV-6c,  SV-lb 

Local 

Commander/Headquarters 

Description:  See  OV-2  Operational  Node 

Description. 

Type:  Swimlane/  Operational  Node 

Views:  OV-1,  OV-2,  OV-5,  OV-6c,  SV-lb 

GPS  Satellites 

Description:  See  OV-1  High-Level  Operational 
Concept  Graphics. 

Type:  Swimlane/  Operational  Node 

Views:  OV-1,  OV-2,  OV-5,  OV-6c,  SV-lb 

Strike  Assets 

Description:  See  OV-1  High-Level  Operational 
Concept  Graphics. 

Type:  Swimlane/  Operational  Node 

Views:  OV-1,  OV-2,  OV-5,  OV-6c,  SV-lb 

Graphical  Box  Types: 

Unit  of  Behavior/Action 

Direct  Mission 

Description:  This  action  is  the  initiating  action  of 
the  sequence.  A  mission  for  the  Friendly  Ground 
Unit  is  assigned  and  communicated  to  it.  It  occurs 
in  the  external  system  Local  Commander/ 
Headquarters. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.1 

OV-5  Reference:  A-2 

Views:  OV-6c 

Decision  to  Launch  MAV 

Description:  This  action  can  take  place  once  a 
mission  has  been  assigned.  It  is  the  act  of  deciding 
to  employ  the  MAV  system  to  complete  all  or  part 
of  the  mission.  The  Friendly  Ground  Unit  performs 
this  action. 

Continued  on  next  page 
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Description 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.2 

OV-5  Reference:  All 

Views:  OV-6c 

Receive  GPS  Signals 

Description:  This  action  receives  the  GPS  signals 
sent  by  satellites,  converts  them  into  useable 
navigation  data,  and  determines  the  location  of  the 
MAV  respectively.  This  action  is  performed  by  the 
MAV. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.3 

OV-5  Reference:  A31 

Views:  OV-6c 

Send  GPS  Signal 

Description:  This  action  sends  GPS  signals  to  the 
MAV  for  use  in  navigation.  The  external  system 

GPS  Satellites  performs  this  action.  In  this 
architecture  it  is  assumed  that  the  action  of  Send 

GPS  Signals  is  occurring  and  continues  to  occur  in 
a  sufficient  manner  to  allow  for  proper  navigation 
by  the  MAV. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.4 

OV-5  Reference:  A-l 

Views:  OV-6c 

Initialize  System 

Description:  This  action  is  a  combination  of  the 
following  tasks:  1)  unpack  and  setup  all 
components  of  the  MAV  system  to  include  the 
ground  station,  user  interface,  MAV,  etc.,  2) 
program  initial  flight  plan  if  necessary,  and  3) 
calibrate  the  MAV.  While  the  first  action  is 
temporally  necessary  before  the  other  two,  the  latter 
two  actions  can  occur  independent  of  each  other. 

All  of  the  actions  are  the  responsibility  of  the 
Friendly  Ground  Unit. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.5 

OV-5  Reference:  A21 

Views:  OV-6c 

Continued  on  next  page 
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Description 

MAV  Ready  for  Launch 

Description:  This  action  is  a  systems  check  and 
confirmation  of  operationally  ready  status  of  the 
MAV.  This  action  notifies  the  Friendly  Ground  Unit 
that  the  MAV  is  ready  for  launch.  It  is  in  response 
to  the  calibrate  function  within  the  previous 

Initialize  System  action.  This  action  is  the 
responsibility  of  the  MAV. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.6 

OV-5  Reference:  A2 

Views:  OV-6c 

Launch  MAV 

Description:  This  action  is  the  physical  act  of 
lofting  the  MAV  into  the  air  to  allow  its  flight 
systems  to  take  over  maintaining  flight.  It  is  an 
action  that  the  Friendly  Ground  Unit  is  responsible 
for. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.7 

OV-5  Reference:  A24 

Views:  OV-6c 

Update  Mission  Profile 

Description:  This  action  allows  the  friendly  ground 
unit  to  either  re-program  a  different  mission  profile 
or  fly  the  MAV  manually  (i.e.  real-time  mission 
profile  updating).  The  Friendly  Ground  Unit  is 
responsible  for  this  action. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.8 

OV-5  Reference:  A23 

Views:  OV-6c 

Continued  on  next  page 
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Description 

Perform  Mission  Profile 

Description:  This  action  encompasses  all  of  the 
actions  necessary  for  the  MAV  to  maintain  flight  in 
the  manner  set  forth  by  the  mission  profile  that  it 
has  been  programmed  with.  It  includes  flying  to  set 
waypoints,  responding  to  direct  navigation 
commands  (turn,  climb,  descend,  etc.),  or  any  other 
flight  plan  that  the  Friendly  Ground  Unit  commands 
it  to  perform  as  allows  by  the  rules  of 
aerodynamics.  This  action  is  the  responsibility  of 
the  MAV. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.9 

OV-5  Reference:  A3 

Views:  OV-6c 

Direct  Land  Sequence 

Description:  This  action  is  the  act  of  the  Friendly 
ground  unit  commanding  the  MAV  system  to  enter 
into  a  landing  sequence.  It  includes  the  initial 
command  to  land  the  MAV  as  well  as  any  info 
processing  and  transmittal  of  that  info  to  the  MAV 
that  it  would  require  to  perform  the  land  sequence. 

It  could  be  a  command  to  return  to  base,  land  at 
current  location,  or  another  location  as  specified. 

This  action  is  the  responsibility  of  the  Friendly 
Ground  Unit. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.10 

OV-5  Reference:  A12 

Views:  OV-6c 

Receive  Sensor  Info 

Description:  This  action  is  the  act  of  the  friendly 
ground  unit  receiving  sensor  info  sent  from  the 

MAV.  It  is  the  responsibility  of  the  Friendly  Ground 
Unit. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.11 

OV-5  Reference:  A12 

Views:  OV-6c 
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Description 

Collect  Sensor  Info 

Description:  This  action  is  the  MAV  sensor  system 
obtaining  information  as  directed.  The  sensors 
could  be  many  types  (still  camera,  video  camera,  IR 
camera,  NBC  sniffer,  etc.).  It  is  the  responsibility  of 
the  MAV  to  perform  this  act. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.12 

OV-5  Reference:  A33 

Views:  OV-6c 

Perform  Land  Sequence 

Description:  This  action  is  the  MAV  responding  to 
the  command  of  the  friendly  ground  unit  to  land 
and  performing  that  landing.  It  is  the  responsibility 
of  the  MAV. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.13 

OV-5  Reference:  A43 

Views:  OV-6c 

Process  Info 

Description:  This  action  is  the  friendly  ground  unit 
processing  the  collected  sensor  info  from  the  MAV 
into  usable  ISR  info.  It  includes  image  processing, 
data  overlay  (GPS  coordinates,  descriptors,  etc), 
and  formatting  for  human  user  interface.  It  is  the 
responsibility  of  the  Friendly  Ground  Unit. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.14 

OV-5  Reference:  All 

Views:  OV-6c 

Recover  MAY 

Description:  This  is  the  physical  act  of  retrieving 
the  MAV  from  its  landing  position  and  preparing  it 
for  either  another  mission  or  stowed  transport.  It  is 
the  responsibility  of  the  Friendly  Ground  Unit. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.15 

OV-5  Reference:  A44 

Views:  OV-6c 
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Transmit  Sensor  Info 

Description:  This  action  is  the  MAV  packaging  and 
transmitting  of  the  collected  sensor  info  back  to  the 
friendly  ground  unit.  It  is  the  responsibility  of  the 
MAV. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.16 

OV-5  Reference:  A33 

Views:  OV-6c 

Transmit  ISR  Info 

Description:  This  action  is  the  friendly  ground  unit 
packaging  and  sending  the  ISR  info  as  necessary  to 
either  the  Local  Commander/  Headquarters  or 

Strike  Assets.  The  Friendly  Ground  Unit  is 
responsible  for  this  action. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.17 

OV-5  Reference:  All 

Views:  OV-6c 

Receive  ISR  Info 

Description:  This  action  is  Local  Commander/ 
Headquarters  receiving  the  ISR  info  sent  from  the 
friendly  ground  unit.  It  is  the  responsibility  of  the 
external  system  Local  Commander/  Headquarters. 
Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.18 

OV-5  Reference:  A-2 

Views:  OV-6c 

Receive  ISR  Info 

Description:  This  action  is  the  Strike  Assets 
receiving  the  ISR  info  sent  from  the  friendly  ground 
unit.  It  is  the  responsibility  of  the  external  system 
Strike  Asset. 

Type:  Unit  of  Behavior/  Action 

Reference  ID:  1.19 

OV-5  Reference:  A-3 

Views:  OV-6c 

Graphical  Arrow  Types 

Links 

Description:  All  links  represent  precedence 
between  actions.  All  links  imply  that  the  task 
pointed  to  cannot  occur  until  the  task  pointed  from 

occurs. 

Continued  on  next  page 
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Type:  Temporal 

Junction 

Description:  The  junction  allows  alternate  paths  to 
occur.  The  one  junction  that  occurs  in  this  view 
denotes  that  once  Launch  MAV  has  occurred, 

Update  Mission  Profile,  Direct  Land  Sequence ,  or 
Perform  Mission  Profile  can  then  occur.  It  also 
provides  a  tie-in  to  allow  Update  Mission  Profile  to 
affect  the  Perform  Mission  Profile  action.  In  other 
words,  manual  inputs  can  then  affect  how  the  MAV 
performs  its  mission. 

Type:  NA 
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Table  J.l  -  AY-2  Integrated  Dictionary 


Entities,  Attributes,  and 
Relationships 

Description 

Graphical  Box  Types: 

Entities 

Navigation  Data 

Description:  Entity  that  represents  positional  data 
provided  by  the  GPS  constellation  for  use  by  the 
MAV. 

Type:  Independent  Entity 

Keys:  SatPRN  (PK) 

Dependent  Entities:  Raw  Data 

Attributes:  Ephemeris 

Tasking 

Description:  Entity  containing  information  required 
to  uniquely  identify  each  tasking. 

Type:  Independent  Entity 

Keys:  TaskID  (PK) 

Dependent  Entities:  User  Commands 

Attributes:  Requester,  Priority,  Instructions 

System  Status 

Description:  Entity  containing  MAV  ISR  system 
fault  information. 

Type:  Dependent 

Keys:  Status  (PK),  VehiclelD  (FK),  SensorlD  (FK), 
SatPRN  (FK) 

Dependent  Entities:  User  Commands 

Attributes:  MAVLaunch  Fault,  Airframe  Fault, 
Ground  Station  Fault,  Navigation  Fault 

User  Commands 

Description:  Entity  containing  the  information 
relevant  for  the  initialization  and  use  of  the  MAV 

ISR  collection  system. 

Type:  Dependent 

Keys:  TaskID  (PFK),  Status  (PFK) 

Attributes:  Flight  Plan 

Raw  Flight  Telemetry  Data 

Description:  Entity  containing  unprocessed  vehicle 
telemetry  information. 

Type:  Category 

Keys:  VehiclelD  (PK), SatPRN  (FK) 

Attributes:  Vehicle  Parameters 

Raw  Sensor  Package  Data 

Description:  Entity  containing  unprocessed 
information  gathered  by  the  sensor  package. 

Continued  on  next  page 
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Relationships 

Description 

Type:  Category 

Keys:  SensorlD  (PK) 

Attributes:  Sensor  Data 

Raw  Data 

Description:  Entity  containing  unprocessed  MAV 

ISR  platform  and  sensor  information. 

Type:  Generic  Dependent 

Keys:  VehiclelD  (PK),  SensorlD  (PK),  TaskID 
(PFK),  Status  (PFK),  SatPRN(PFK) 

Attributes:  Decoded  Sensor  Package  Data, 
FaultCodes 

Fused  Target  Information 

Description:  Entity  containing  the  processed  MAV 
ISR  information. 

Type:  Dependent 

Keys:  TaskID  (PFK),  VehiclelD  (FK),  SensorlD 
(FK),  SatPRN(FK) 

Attributes:  ISR  Information 

Graphical  Arrow  Types: 

Relationships 

Tasking  to  User  Commands 

Relationship:  Required  for 

Multiplicity:  1-*  to  1 

System  Status  to  Navigation 

Relationship:  Requires 

Data 

Multiplicity:  1  to  0..* 

User  Commands  to  System 

Relationship:  Requires 

Status 

Multiplicity:  1  to  1 

Raw  Data  to  Navigation  Data 

Relationship:  Uses 

Multiplicity:  1  to  1..* 

System  Status  to  Raw  Data 

Relationship:  interprets 

Multiplicity:  1  to  1 

Raw  Data  to  User  Commands 

Relationship:  Requires 

Multiplicity:  1..*  to  1 

Fused  Target  Information  to 

Relationship:  Requires 

Raw  Data 

Multiplicity:  1  to  1„* 
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AS-IS  (ISR  MAV) 

Logical  Data  Model  OV-7 


Figure  J.  1  Logical  Data  Model  (OV-7) 
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Table  K.l  -  AY-2  Integrated  Dictionary 


Entities,  Attributes,  and 
Relationships 

Description 

Graphical  Box  Types: 

System  Nodes 

Friendly  Ground  Unit 

Synonymous  with  the  Friendly  Ground  Unit 
operational  node  (reference  the  OV-2  definition 
table) 

MAV 

Synonymous  with  the  MAV  operational  node 
(reference  the  OV-2  definition  table) 

Graphical  Box  Types: 

Systems 

Air  Vehicle 

Description:  The  Air  Vehicle  system  allows  other 
systems  within  the  MAV  system  node  to  operate  as 
airborne  systems.  Functions  performed  by  this 
system  include:  Take  Flight,  Flight  Control,  Power 
Source,  and  Flight  Data  Protocol.  Examples  of 
hardware  systems  that  could  perform  these 
functions  are  an  aircraft  fuselage  with  wings, 
autopilot,  and/or  a  battery.  Synonymous  to  Perform 
Air  Vehicle  Functions. 

Type:  System 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Field  Communication  System 

Description:  The  Field  Communication  System 
allows  the  Human  Operator  to  communicate 
gathered  ISR  information  and  mission  directives 
with  higher  Headquarters  and/or  Strike  Assets. 

Such  a  system  can  include  items  such  as  SATCOM 
or  a  hand  held  radio.  This  system  performs  the 
following  functions:  Transmit  ISR  Info,  Receive 
Directives,  Modulate  ISR  Info,  and  De-Modulate 
Directives.  Synonymous  to  Provide  Field 
Communication. 

Type:  System 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

GPS  Satellites 

Description:  The  Global  Positioning  System 
consists  of  a  constellation  of  satellites  providing 
pseudorange  numbers  and  ephemeris  data.  Ground 
based  receivers  use  this  information  to  calculate 
their  location. 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Type:  External  System 

Views:  OV-1,  OV-2,  OV-3,  OV-6c,  SV-lb,  SV-lc, 
SV-4,  SV-6 

Headquarters 

Description:  Headquarters  encompasses  any  unit  or 
group  that  the  operator  is  required  to  report  to,  or  is 
considered  at  a  higher  level  in  the  operators  chain 
of  command.  This  unit  can  be  stationed  locally  in 
respect  to  the  operator  (in  the  field)  or  remote  (far 
away  from  the  operator).  Headquarters  can  do  any 
number  of  tasks,  including  making  decisions  based 
on  gathered  intelligence,  assigning  missions  or 
directives  to  field  units,  or  providing  intelligence 
information.  Synonymous  to  AOC  or  Local 
Commanders. 

Type:  External  System 

Views:  OV-1,  OV-2,  OV-3,  OV-6c,  SV-lb,  SV-lc, 
SV-4,  SV-6 

Human  Computer  Interface 
(HCI) 

Description:  The  HCI  system  includes  those  items 
that  give  feedback  (display,  speakers)  to  users,  or 
Human  Operator,  as  well  as  those  that  allow  users  to 
supply  input  to  the  system  (keyboard,  mouse,  touch 
screen,  microphone).  Its  system  functions  include 
Give  Feedback  and  Accept  Input.  Synonymous  to 
Provide  Human  Computer  Interface. 

Type:  System 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Human  Operator 

Description:  The  Human  Operator  system  is  a 
model  of  the  operators  role  in  the  system.  The 
operator  either  affects  the  system  through  direct 
contact  (Platform  Interface  and  Field  Comm 
Interface),  through  the  HCI  system  (User  Feedback 
and  Inputs  interface),  or  through  the  request  of 
outside  maintenance  to  the  Maintenance  Depot 
system.  Functions  performed  by  the  Human 

Operator  are  Process  Info,  Influence  System,  Route 
Info,  and  Maintain  System.  Synonymous  to 

Perform  Human  Operator  Functions. 

Type:  System 

Continued  on  next  page 
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Description 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Maintenance  Depot 

Description:  The  Maintenance  Depot  includes  any 
unit  or  outside  system  that  performs  maintenance  or 
support  on  all  internal  systems.  Although  the 
diagram  only  shows  an  interface  with  the  Human 
Operator  system,  the  Maintenance  Depot  actually 
interfaces  with  all  systems  in  both  system  nodes. 
Since  this  maintenance  function  is  viewed  external 
its  interfaces  are  not  shown.  To  better  define,  the 
main  purpose  of  this  system  is  to  perform 
maintenance  that  cannot  be  performed  in  the  field 
by  the  Human  Operator. 

Type:  External  System 

Views:  OV-2,  OV-3,  OV-6c,  SV-lb,  SV-lc,  SV-6 

MAV  Airborne 

Communication  System 

Description:  The  MAV  Airborne  Communication 
System  allows  airborne  systems  (MAV)  to 
communicate  gathered  data,  directives,  and  status 
information  with  ground  systems  (Friendly  Ground 
Unit).  This  system  accomplishes  this  by  ensuring 
that  data  can  be  sent  to  and  received  from  the  MAV 
Ground  Communication  System.  System  functions 
include:  Transmit  Data,  Receive  MAV  Directives, 
Modulate  Data,  De-Modulate  MAV  Directives,  and 
Accept  Supplied  Power.  Examples  of  such 
hardware  equipment  include  transmitters,  receivers 
and  antennas.  Synonymous  to  Provide  MAV 

Airborne  Communication  System. 

Type:  System 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Continued  on  next  page 
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Description 

MAV  Ground  Communication 
System 

Description:  The  MAV  Ground  Communication 
System  allows  ground  systems  (Friendly  Ground 
Unit)  to  communicate  directives  with  the  airborne 
systems  (MAV).  This  system  accomplishes  this  by 
ensuring  that  data  can  be  sent  to  and  received  from 
the  MAV  Airborne  Communication  System. 

System  functions  include:  Transmit  MAV 

Directives,  Receive  Data,  Modulate  MAV 

Directives,  and  De-Modulate  Data.  Examples  of 
such  hardware  equipment  include  transmitters, 
receivers  and  antennas.  Synonymous  to  Provide 

MAV  Ground  Communication  System. 

Type:  System 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Payload  or  Sensor  Package 

Description:  The  Payload  or  Sensor  Package 
systems  purpose  is  to  collect  and  provide  the 
needed  ISR  information.  It  accomplishes  this  by 
performing  the  following  functions:  Enable  ISR 
Capability,  Convert  Data,  and  Payload  Data 

Protocol.  This  system  utilizes  the  power  source 
supplied  by  the  Air  Vehicle  system  to  obtain  ISR 
information  and  send  it  to  the  MAV  Airborne 
Communication  System.  Synonymous  to  Perform 
Payload  or  Sensor  Package  Functions. 

Type:  System 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Signal/Data  Processor 

Description:  The  Signal/Data  Processor  system 
Processes,  Converts,  and  Manipulates  data  (those 
are  the  system  functions)  such  that  the  proper  data 
packets  can  be  delivered  to  the  HCI  and  the  MAV 
Ground  Communication  System. 

Type:  System 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Strike  Assets 

Description:  Strike  assets  are  any  operational  unit 
that  has  the  capability  to  inflict  damage  on  the 
enemy.  Examples  include  aircraft  (A- 10),  ground 
units  (artillery),  or  sea  based  units  (cruiser). 

Type:  External  System 

Continued  on  next  page 
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Description 

Views:  OV-1,  OV-2,  OV-3,  OV-6c,  SV-lb,  SV-lc, 
SV-4,  SV-6 

Graphical  Arrow  Types: 

Interfaces 

BDI  Request  and  Feedback 

Description:  Included  in  this  interface  are  BDI 
request  and  feedback  sent  from  and  to  the  Strike 
Assets  through  the  Field  Communication  System. 
BDI  request  include  the  type  of  strike,  last  known 
enemy  positions  (or  location  of  strike)  using  a 
standardized  coordinate  system,  and  when  the  strike 
is  scheduled  (if  not  already  occurred).  BDI 
feedback  includes  general  information  sent  back  to 
the  strike  asset  concerning  BDI  mission  results. 
Synonymous  with  Communicate  with  Local  Strike 
Assets. 

Endpoint  1:  Strike  Assets 

Endpoint  2:  Field  Communication  System 

Type:  External  Interface 

Views:  OV-2,  OV-3,  SV-lb,  SV-lc,  SV-6 

Feedback  and  Input  Data 

Description:  The  Feedback  and  Input  Data  interface 
includes  any  information  sent  to  or  from  the 
operator  through  the  HCI.  Feedback  is  sent  from 
the  Signal/Data  Processor  system  to  the  HCI  while 
Input  Data  is  sent  from  the  HCI  to  the  Signal/Data 
Processor. 

Endpoint  1 :  Human  Computer  Interface 

Endpoint  2:  Signal/Data  Processor 

Type:  System  Interface 

Views:  SV-lc  (Friendly  Ground  Unit) ,  SV-6 

Field  Comm  Interface 

Description:  The  Field  Comm  Interface  includes  all 
information  sent  to  the  Human  Operator  from 
external  systems  or  vice  versa  using  the  Field 
Communication  System.  This  interface  can  include 
audible  or  visual  data. 

Endpoint  1 :  Human  Operator 

Endpoint  2:  Field  Communication  System 

Type:  System  Interface 

Views:  SV-lc  (Friendly  Ground  Unit) ,  SV-4,  SV-6 

Continued  on  next  page 

K-5 


Table  K.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Information  Gathered,  Mission 
Tasks,  Intelligence  Info 

Description:  As  the  name  implies  this  link  includes 
sending  ISR  information  gathered  to  Headquarters, 
and  receiving  both  mission  tasks  and  intelligence 
information  from  Headquarters.  Synonymous  with 
Communicate  with  Headquarters. 

Endpoint  1:  Headquarters 

Endpoint  2:  Field  Communication  Interface 

Type:  External  Interface 

Views:  OV-2,  OV-3,  SV-lb,  SV-lc,  SV-6 

Maintenance  Required 

Description:  This  interface  depicts  interaction 
between  the  Human  Operator  and  the  Maintenance 
Depot.  Included  here  is  the  Human  Operators 
request  for  maintenance  to  be  performed  on  any 
system  within  the  system  nodes  and  the 

Maintenance  Depots  acknowledgement  of 
completed  maintenance.  Such  maintenance 
requests  occur  whenever  the  Human  Operator  is  not 
capable  or  it  is  out  of  the  scope  of  the  Maintain 
System  function  (implying  field  level  maintenance). 
Endpoint  1 :  Maintenance  Depot 

Endpoint  2:  Human  Operator 

Type:  External  Interface 

Views:  SV-lb,  SV-lc  (Friendly  Ground  Unit),  SV-6 

MAV  Directives  and  Payload 
Data 

Description:  The  MAV  Directives  and  Payload  Data 
interface  encompasses  directives  to  be  sent  to  the 

Air  Vehicle  system  and  payload  data  to  be  sent  to 
the  Signal/Data  Processor.  Directives  primarily 
include  flight  control  data  and  are  first  sent  to  the 
MAV  Ground  Communications  System.  Payload 
Data  includes  any  ISR  data  gathered  and  sent  by  the 
Payload  or  Sensor  Package  system. 

Endpoint  1:  Signal/Data  Processor 

Endpoint  2:  MAV  Ground  Communications  System 
Type:  System  Interface 

Views:  SV-lc  (Friendly  Ground  Unit) ,  SV-6 
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Navigation  Data 

Description:  Depending  on  the  view,  navigation 
data  can  either  be  an  operational  needline  (OVs)  or 
an  external  interface  (SVs).  This  link  includes  the 
pseudorange  numbers  and  ephemeris  data 
transmitted  by  the  GPS  satellites. 

Endpoint  1:  GPS  Satellites 

Endpoint  2:  Air  Vehicle 

Type:  External  Interface 

Views:  OV-1,  OV-2,  OV-3,  OV-5,  OV-7,  SV-lb, 
SV-lc,  SV-4,  SV-6 

Payload  Data 

Description:  The  Payload  Data  interface  represents 
ISR  data  collected  by  the  Payload  or  Sensor 

Package  system  sent  to  the  MAV  Airborne 
Communication  System.  This  interface  includes 
data  that  has  been  converted  and  is  ready  to  be 
accepted  by  the  MAV  Airborne  Communication 
System. 

Endpoint  1 :  Payload  or  Sensor  Package 

Endpoint  2:  MAV  Airborne  Communication 

System 

Type:  System  Interface 

Views:  SV-lc  (MAV) ,  SV-4,  SV-6 

Platform  Interface 

Description:  The  Platform  Interface  involves  any 
direct  contact  between  the  Human  Operator  and  Air 
Vehicle  systems.  This  can  include  actions  to 
perform  maintenance,  set-up,  or  tear-down 
functions. 

Endpoint  1 :  Human  Operator 

Endpoint  2:  Air  Vehicle 

Type:  System  Interface 

Views:  SV-lb,  SV-lc,  SV-4,  SV-6 

Power  Interface 

Description:  The  Power  Interface  represents  the 
link  between  a  power  source  within  the  Air  Vehicle 
system  and  the  Payload  or  Sensor  Package  system. 

If  no  power  is  required  by  the  Payload  or  Sensor 
Package  system  then  this  interface  does  not  exists. 
Synonymous  to  Power. 

Endpoint  1 :  Air  Vehicle 
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Endpoint  2:  Payload  or  Sensor  Package 

Type:  System  Interface 

Views:  SV-lc  (MAV) ,  SV-4,  SV-6 

Power,  MAV  Directives,  and 
Status  Interface 

Description:  The  Power,  MAV  Directives,  and 

Status  Interface  represents  three  links.  The  first  is  a 
link  between  a  power  source  within  the  Air  Vehicle 
and  the  MAV  Airborne  Communication  System.  If 
no  power  is  required  by  the  Airborne 

Communication  System  then  the  power  interface 
piece  does  not  exists.  The  second  link  is  MAV 
Directives  sent  from  the  Airborne  Communication 
System  to  the  Air  Vehicle.  These  directives  include 
mainly  flight  control  data.  And  the  third  link 
contains  flight  status  information  sent  from  the  Air 
Vehicle  to  the  MAV  Airborne  Communication 
System;  such  information  includes  present  location 
of  the  MAV. 

Endpoint  1 :  Air  Vehicle 

Endpoint  2:  MAV  Airborne  Communication 

System 

Type:  System  Interface 

Views:  SV-lc  (MAV) ,  SV-6 

Request  /  Commands,  ISR 

Data 

Description:  The  Request/Commands,  ISR  Data 
Interface  includes  all  airborne  communications 
between  the  Friendly  Ground  Unit  and  MAV 
system  nodes.  This  system  communication 
interface  includes  request  or  commands  (Raw 

Flight  Telemetry  Data)  sent  from  the  MAV  Ground 
Communication  System  to  the  MAV  Airborne 
Communications  System  and  then  gathered  ISR 
data  (Raw  Sensor  Package  Data)  sent  from  the 
Airborne  to  the  Ground  Communications  System. 
Primarily  this  interface  represents  wireless 
communication  that  has  been  modulated  using  a 
pre-determined  technique  (spread  spectrum). 
Endpoint  1 :  MAV  Ground  Communication  System 
Endpoint  2:  MAV  Airborne  Communication 

System 
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Type:  System  Interface 

Views:  SV-lb,  SV-lc,  SV-6 

User  Feedback  and  Inputs 

Description:  This  interface  includes  any  feedback 
for  the  operator  or  user  as  well  as  inputs  generated 
by  the  operators  actions.  User  feedback  is  sent  from 
the  HCI  to  the  Human  Operator  and  can  include  any 
means  for  a  computer  to  communicate  to  the 
operator  (ex:  visual,  audible  signals).  User  inputs 
are  generated  by  the  Human  Operator  and  are 
gathered  by  the  HCI. 

Endpoint  1 :  Human  Operator 

Endpoint  2:  Human  Computer  Interface  (HCI) 

Type:  System  Interface 

Views:  SV-lc  (Friendly  Ground  Unit) ,  SV-6 

Non-Graphical  Types: 

System  Functions 

Accept  Input 

Description:  This  system  function  is  apart  of  the 

HCI  system.  Its  purpose  is  to  allow  the  user  to 
supply  input  to  the  system  in  an  easy  and  swift 
manner.  The  input  supplied  should  integrate  itself 
with  the  Give  Feedback  system  function  such  that 
the  user  can  see  what  the  system  has  accepted 
before  the  execution. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Accept  Supplied  Power 

Description:  This  system  function  is  apart  of  the 
MAV  Airborne  Communication  System.  Its 
purpose  is  to  consume  and  utilize  the  power 
supplied  by  another  system  within  the  MAV  system 
node;  in  this  case  it  is  from  the  Air  Vehicle  system. 
Note  that  if  no  power  is  needed  by  the  MAV 

Airborne  Communication  System  then  this  function 
does  not  apply. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 
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Convert/Route  Data 

Description:  This  system  function  is  performed  by 
the  Signal/Data  Processor;  its  purpose  is  to  convert 
then  route  data  going  to  other  systems  as  well  as  to 
route  then  convert  data  coming  from  other  systems. 
Converting  implies  performing  operations  on 
received  data  such  that  it  can  be  processed  as  well 
as  on  outgoing  data  such  that  the  gaining  system 
can  read  it.  Routing,  as  the  name  implies,  includes 
sending  the  data  to  the  intended  gaining  unit  as  well 
as  moving  data  internal  to  the  Signal/Data 

Processor  system. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Convert  ISR  Data 

Description:  This  system  function  is  performed  by 
the  Payload  or  Sensor  Package  system;  its  purpose 
is  to  covert  raw  data  such  that  the  gaining  system 
can  read  it.  Examples  include  a  digital  to  analog 
converter. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

De-Modulate  Data 

Description:  This  function  is  apart  of  the  MAV 
Ground  Communication  System;  its  purpose  is  to 
de-modulate  and/or  decrypt  the  Payload  Data  being 
sent  from  the  MAV  Airborne  Communication 
System.  There  are  many  de-modulation  techniques 
and  the  one  that  is  used  is  based  on  the  modulation 
technique  used  by  the  transmitting  system.  If  the 
signal  is  not  modulated  then  this  function  is  void. 
Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

De-Modulate  Directives 

Description:  This  function  is  apart  of  the  Field 
Communication  System,  its  purpose  is  to 
de-modulate  and/or  decrypt  the  mission  directives 
being  sent  from  Headquarters  or  Strike  Assets. 

There  are  many  de-modulation  techniques  and  the 
one  that  is  used  is  based  on  the  modulation 
technique  used  by  the  transmitting  system.  If  the 
signal  is  not  modulated  then  this  function  is  void. 
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Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

De-Modulate  MAV  Directives 

Description:  This  function  is  apart  of  the  MAV 
Airborne  Communication  System;  its  purpose  is  to 
de-modulate  and/or  decrypt  the  MAV  Directives 
(see  MAV  Directives  and  Payload  Data)  being  sent 
from  the  MAV  Ground  Communication  System. 
There  are  many  de-modulation  techniques  and  the 
one  that  is  used  is  based  on  the  modulation 
technique  used  by  the  transmitting  system.  If  the 
signal  is  not  modulated  then  this  function  is  void. 
Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Enable  ISR  Capability 

Description:  This  system  function  is  performed  by 
the  Payload  or  Sensor  Package  system;  its  purpose 
is  to  gather  the  needed  ISR  information.  Sensors 
are  the  main  items  intended  to  perform  this 
function,  however  the  kind  and  type  of  sensor 
should  be  determined  based  on  the  particular  ISR 
mission.  Implied  within  this  function  is  the  ability 
to  accept  supplied  power,  in  this  case  the  power 
being  supplied  is  from  the  Air  Vehicle  system. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Flight  Control 

Description:  This  system  function  is  performed  by 
the  Air  Vehicle  system;  its  purpose  is  to  provide  the 
needed  hardware  and  software  to  follow  the  MAV 
Directives  (flight  control  data).  Such  directives  can 
include  left/right  turns,  altitude  level,  and  flight 
patterns.  System  examples  include  autopilot,  flaps, 
ailerons,  servo  motors,  etc. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 
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Flight  Data  Protocol 

Description:  This  system  function  is  performed  by 
the  Air  Vehicle  system;  its  purpose  is  to 
send/receive  data  to/from  the  MAV  Airborne 
Communication  System  based  on  a  set  of  protocol 
rules.  One  example  of  a  protocol  rule  is  to  send  a 
data  type  stamp  on  each  set  of  data  such  that  the 
gaining  system  knows  what  type  of  data  it  is. 
Depending  on  the  data  bus  structure  and  how  the 
Power,  MAV  Directives,  and  Status  Interface  is 
implemented  this  function  may  be  very  complex, 
simple,  or  not  exists. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5 

Give  Feedback 

Description:  This  system  function  is  apart  of  the 

HCI  system.  Its  purpose  is  to  supply  feedback  to 
the  user  in  an  easy  and  quick  to  understand  method. 
The  feedback  given  should  use  the  same  terms  as 
well  as  integrate  itself  with  the  Accept  Input  system 
function  such  that  the  user  can  react  quickly  and 
accurately. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Influence  System 

Description:  The  Influence  System  function  is 
performed  by  the  Human  Operator;  its  purpose  is  to 
affect  other  systems  through  direct  operator  contact. 
This  function  could  contain  switching  a  switch, 
performing  set-up/tear-down,  pressing  buttons 
resulting  in  system  input,  etc. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 
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Maintain  System 

Description:  This  function  is  performed  by  the 
Human  Operator;  its  purpose  is  similar  to  Influence 
System  however  the  Maintain  System  function 
focuses  only  on  field  level  maintenance  actions. 
Examples  include  changing  batteries,  repairing  a 
wing,  or  installing  a  new  item.  If  the  level  of 
maintenance  is  outside  that  of  what  can  be  done  in 
the  field  then  this  function  acts  as  a  maintenance 
request  function  to  notify  the  Maintenance  Depot  of 
a  problem. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Manipulate  Data 

Description:  This  system  function  is  performed  by 
the  Signal/Data  Processor;  its  purpose  is  similar  to 
the  Process  Data  function  however  data 
manipulation  focuses  on  reprocessing  already 
processed  data.  For  example,  once  data  is  processed 
it  can  be  dumped  into  local  memory  and  then 
reprocessed  or  manipulated  to  better  suit  the 
operators  or  systems  needs  (image  zooming). 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5 

Modulate  Data 

Description:  This  function  is  apart  of  the  MAV 
Airborne  Communication  System;  its  purpose  is  to 
modulate  and/or  encrypt  the  Payload  Data  and 
status  information  being  sent  to  the  MAV  Ground 
Communication  System.  There  are  many 
modulation  techniques  and  the  one  that  is  used  is 
based  on  the  hardware  system  available  or  the 
system  to  receive  the  data  (i.e.  MAV  Ground 
Communication  System).  If  the  system  receiving 
the  Payload  Data  is  not  capable  of  de-modulating 
the  modulated  signal  then  this  function  is  void. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 
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Modulate  ISR  Info 

Description:  This  function  is  apart  of  the  Field 
Communication  System,  its  purpose  is  to  modulate 
and/or  encrypt  the  ISR  information  being  sent  to 
Headquarters  or  Strike  Assets.  There  are  many 
modulation  techniques  and  the  one  that  is  used  is 
based  on  the  hardware  system  available,  Human 
Operator,  or  the  system  to  receive  the  ISR 
information.  If  the  system  receiving  the  ISR 
information  is  not  capable  of  de-modulating  the 
modulated  signal  then  this  function  is  void. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Modulate  MAV  Directives 

Description:  This  function  is  apart  of  the  MAV 
Ground  Communication  System;  its  purpose  is  to 
modulate  and/or  encrypt  the  MAV  Directives  being 
sent  to  the  MAV  Airborne  Communication  System. 
There  are  many  modulation  techniques  and  the  one 
that  is  used  is  based  on  the  hardware  system 
available  or  the  system  receiving  the  data  (i.e.  MAV 
Airborne  Communication  System).  If  the  system 
receiving  the  MAV  Directives  is  not  capable  of 
de-modulating  the  modulated  signal  then  this 
function  is  void. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Payload  Data  Protocol 

Description:  This  system  function  is  performed  by 
the  Payload  or  Sensor  Package  system;  its  purpose 
is  to  send  data  to  the  MAV  Airborne 

Communication  System  based  on  a  set  of  protocol 
rules.  One  example  of  a  protocol  rule  is  to  send  a 
data  type  stamp  on  each  set  of  data  such  that  the 
gaining  system  knows  what  type  of  data  it  is. 
Depending  on  the  data  bus  structure  and  how  the 
Payload  Data  Interface  is  implemented  this  function 
may  be  very  complex,  simple,  or  not  exists. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5 
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Power  Source 

Description:  The  Power  Source  system  function  is 
performed  by  the  Air  Vehicle;  its  purpose  is  to 
provide  all  airborne  systems  (MAV)  a  power 
supply.  Every  airborne  system  has  been  architected 
to  need  a  power  supply,  the  amount  or  type  of 
power  needed  will  be  determined  by  these  systems. 
Examples  of  power  sources  are  a  battery,  liquid 
fuel,  gas,  or  fuel  cell. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Process  Data 

Description:  This  system  function  is  performed  by 
the  Signal/Data  Processor;  its  purpose  is  to  perform 
simple  or  complex  operations  based  on  the  data 
brought  into  the  system.  For  example  after 
receiving  input  data  from  the  HCI  system  the 
Signal/Data  Processor  outputs  a  set  of  MAV 
Directives. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Process  Info 

Description:  This  function  is  performed  by  the 
Human  Operator;  its  purpose  is  to  process  the 
gathered  ISR  information  and  mission  directives. 
Based  on  this  processing,  the  Human  Operator 
decides  the  next  state  of  the  system.  For  example,  if 
the  processing  of  the  gathered  ISR  information 
resulted  in  an  enemy  tank  location  then  the  operator 
could  make  the  decision  to  forward  (or  route)  the 
information  to  Strike  Assets. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Receive  Data 

Description:  This  function  is  performed  by  the 

MAV  Ground  Communication  System;  its  purpose 
is  to  receive  Payload  Data  and  status  information 
from  the  MAV  Airborne  Communication  System 
for  the  Signal/Data  Processor  system. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 
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Receive  Directives 

Description:  This  function  is  apart  of  the  Field 
Communication  System,  its  purpose  is  to  provide 
the  Human  Operator  with  mission  directives 
derived  from  Headquarters  or  Strike  Assets.  The 
hardware  and  software  involved  in  receiving  the 
directives  should  be  based  on  the  operators 
common  scenario  and  mission. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Receive  MAV  Directives 

Description:  This  function  is  performed  by  the 

MAV  Airborne  Communication  System;  its  purpose 
is  to  receive  directives  from  the  MAV  Ground 
Communication  System  for  the  Air  Vehicle  system. 
Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Route  Info 

Description:  This  function  is  performed  by  the 
Human  Operator;  its  purpose  is  to  route  the 
processed  ISR  information  or  mission  directives  to 
the  appropriate  system  (Headquarters,  Strike 

Assets,  or  the  HCI).  Only  the  processed  data  needed 
by  the  gaining  system  will  be  routed. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Take  Flight 

Description:  This  function  is  performed  by  the  Air 
Vehicle  system;  its  purpose  is  to  utilize  the  laws  of 
aerodynamics  to  ensure  that  systems  with  in  the 

MAV  node  can  become  airborne.  Take-off,  landing, 
and  flight  sustainment  are  implied  within  this 
system  function. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5 
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Transmit  Data 

Description:  The  Transmit  Data  system  function  is 
performed  by  the  MAV  Airborne  Communication 
System;  its  purpose  is  to  transmit  data  generated  by 
the  payload  (Payload  Data  interface)  as  well  as 
status  information  generated  by  the  Air  Vehicle 
system  (Power,  MAV  Directives,  and  Status 

Interface)  to  the  MAV  Ground  Communication 
System. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Transmit  ISR  Info 

Description:  This  function  is  apart  of  the  Field 
Communication  System,  its  purpose  is  to  provide 
Headquarters  or  Strike  Assets  ISR  information.  The 
hardware  and  software  involved  in  transmitting  the 
information  should  be  based  on  the  operators 
common  scenario  and  mission. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Transmit  MAV  Directives 

Description:  The  Transmit  MAV  Directives  system 
function  is  performed  by  the  MAV  Ground 
Communication  System;  its  purpose  is  to  transmit 
directives  for  the  Air  Vehicle  system  generated  by 
the  Signal/Data  Processor  system  to  the  MAV 
Airborne  Communication  System. 

Type:  System  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Referenced  Types 

Needline 

See  OV-2  Definition  Table 

Operational  Node 

See  OV-2  Definition  Table 

Relationships 

Systems  Node 

Systems 

Friendly  Ground  Unit 

Human  Operator,  Human  Computer  Interface 
(HCI),  Signal/Data  Processor,  Field 

Communication  System,  MAV  Ground 
Communication  System 

MAV 

Air  Vehicle,  Payload  or  Sensor  Package,  MAV 
Airborne  Communication  System 

System  (within  system  nodes) 

System  Functions 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Air  Vehicle 

Take  Flight,  Flight  Control,  Power  Source,  Flight 
Data  Protocol 

Field  Communication  System 

Transmit  ISR  Info,  Receive  Directives,  Modulate 

ISR  Info,  De-Modulate  Directives 

Human  Computer  Interface 
(HCI) 

Give  Feedback,  Accept  Input 

Human  Operator 

Process  Info,  Influence  System,  Route  Info, 

Maintain  System 

MAV  Airborne 

Communication  System 

Transmit  Data,  Receive  MAV  Directives,  Modulate 
Data,  De-Modulate  MAV  Directives,  Accept 

Supplied  Power 

MAV  Ground  Communication 
System 

Transmit  MAV  Directives,  Receive  Data,  Modulate 
MAV  Directives,  De-Modulate  Data 

Payload  or  Sensor  Package 

Enable  ISR  Capability,  Convert  ISR  Data,  Payload 
Data  Protocol 

Signal/Data  Processor 

Convert/Route  Data,  Process  Data,  Manipulate  Data 

System  Node 

Operational  Node 

Friendly  Ground  Unit 

Friendly  Ground  Unit 

MAV 

MAV 

System  Interface  (SV-lb 
only) 

Operational  Needline 

BDI  Request  and  Feedback 

Communicate  with  Local  Strike  Assets 

Information  Gathered,  Mission 
Tasks,  Intelligence  Info 

Communicate  with  Headquarters 

Maintenance  Required 

System  Maintenance  Needed/Request 

Navigation  Data 

Navigation  Data 

Platform  Interface 

Platform  Communication 

Request/Commands,  ISR  Data 

Platform  Communication 

K-18 
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Figure  K.l  SV-lb  Systems  Interface  Description:  Internodal  Version  showing  System- 
System  Interfaces 
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Figure  K.2  SV-lc  Systems  Interface  Description:  Intranodal  Version  of  the  Friendly 
Ground  Unit  showing  System-System  Interfaces  and  System  Functions 
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Figure  K.3 


SV-lc  Systems  Interface  Description:  Intranodal  Version  of  the  MAV 
showing  System-System  Interfaces  and  System  Functions 
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Appendix  L.  MAV  SV-4 


Table  L.l  -  AV-2  Integrated  Dictionary 


Entities,  Attributes,  and 
Relationships 

Description 

Graphical  Box  Types: 

External  System  Data  Source/Sink 

Strike  Asset 

Description:  See  OV-1  Definition  Table 

Views:  OV-1,  OV-2,  OV-3,  OV-5,  OV-6c,  SV-lb, 
SV-lc,  SV-4,  SV-5,  SV-6 

Headquarters 

Description:  See  OV-1  (AOC)  and  OV-2  Definition 
Tables 

Views:  OV-1,  OV-2,  OV-3,  OV-5,  OV-6c,  SV-lb, 
SV-lc,  SV-4,  SV-5,  SV-6 

GPS  Satellites 

Description:  See  OV-1  Definition  Table 

Views:  OV-1,  OV-2,  OV-3,  OV-5,  OV-6c,  SV-lb, 
SV-lc,  SV-4,  SV-5,  SV-6 

Graphical  Box  Types: 

System  Function 

Accept  Input 

Description:  See  SV-1  Definition  Table 

Reference:  1.2.2 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Accept  Supplied  Power 

Description:  See  SV-1  Definition  Table 

Reference:  2.1.4 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Convert/Route  Data 

Description:  See  SV-1  Definition  Table 

Reference:  1.1.2 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Convert  ISR  Data 

Description:  See  SV-1  Definition  Table 

Reference:  2.3.3 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

De-Modulate  Data 

Description:  See  SV-1  Definition  Table 

Reference:  1.5.3 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

De-Modulate  Directives 

Description:  See  SV-1  Definition  Table 

Reference:  1.3.4 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

De-Modulate  MAV  Directives 

Description:  See  SV-1  Definition  Table 

Reference:  2.1.3 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Enable  ISR  Capability 

Description:  See  SV-1  Definition  Table 

Reference:  2.3.2 

Continued  on  next  page 
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Table  L.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Flight  Control 

Description:  See  SV-1  Definition  Table 

Reference:  2.2.1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Flight  Data  Protocol 

Description:  See  SV-1  Definition  Table 

Reference:  2.2.3 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Give  Feedback 

Description:  See  SV-1  Definition  Table 

Reference:  1.2.1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Influence  System 

Description:  See  SV-1  Definition  Table 

Reference:  1.4.3 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Maintain  System 

Description:  See  SV-1  Definition  Table 

Reference:  1.4.4 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Manipulate  Data 

Description:  See  SV-1  Definition  Table 

Reference:  1.1.1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Modulate  Data 

Description:  See  SV-1  Definition  Table 

Reference:  2.1.5 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Modulate  ISR  Info 

Description:  See  SV-1  Definition  Table 

Reference:  1.3.3 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Modulate  MAV  Directives 

Description:  See  SV-1  Definition  Table 

Reference:  1.5.1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Payload  Data  Protocol 

Description:  See  SV-1  Definition  Table 

Reference:  2.3.1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Perform  Air  Vehicle  Functions 

Description:  This  function  represents  the  aggregate 
of  ah  lower  functions  performed  by  the  Air  Vehicle 
part  of  the  MAV  system.  It  is  the  sum  of  the 
sub-functions  Flight  Control,  Take  Flight,  Flight 
data  Protocol,  and  Power  Source. 

Reference:  2.2 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Continued  on  next  page 
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Table  L.l  -  continued  from  previous  page 


Entities,  Attributes,  and 
Relationships 

Description 

Perform  Ground  Unit 

Functions 

Description:  This  function  represents  the  aggregate 
of  all  lower  functions  performed  by  the  Ground 

Unit.  It  is  the  sum  of  the  sub-functions  Signal/  data 
Processing,  Provide  Human  Computer  Interface, 
Provide  Field  Communication,  Perform  Human 
Operator  Functions,  and  Provide  MAV  Ground 
Communication. 

Reference:  1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Perform  Human  Operator 
Functions 

Description:  This  function  represents  the  aggregate 
of  all  lower  sub-functions  performed  by  the  Human 
Operator.  It  is  the  sum  of  the  sub-functions  Route 
Info,  Process  Info,  Influence  system,  and  Maintain 
System. 

Reference:  1.4 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Perform  MAV  Functions 

Description:  This  function  represents  the  aggregate 
of  all  lower  functions  performed  by  the  MAV.  It  is 
the  sum  of  the  sub-functions  Provide  MAV 

Airborne  Communication,  Perform  Air  Vehicle 
Functions  and  Perform  Payload/  Sensor  Functions. 
Reference:  2 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Perform  Payload/  Sensor 
Functions 

Description:  This  function  represents  the  aggregate 
of  all  lower  functions  performed  by  the  Payload/ 
Sensor.  It  is  the  sum  of  the  sub-functions  Payload 
Data  Protocol,  Enable  ISR  Capability,  and  Convert 
ISR  Data. 

Reference:  2.3 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Power  Source 

Description:  See  SV-1  Definition  Table 

Reference:  2.2.4 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Process  Data 

Description:  See  SV-1  Definition  Table 

Reference:  1.1.3 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Process  Info 

Description:  See  SV-1  Definition  Table 

Reference:  1.4.2 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Provide  Field  Communication 

Description:  This  function  represents  the  aggregate 
of  all  lower  functions  performed  by  the  Field 
Communication  sub-system.  It  is  the  sum  of  the 
sub-functions  Transmit  ISR  Information,  Receive 
Directives,  Modulate  ISR  Information,  and 
De-Modulate  Directives. 

Reference:  1.3 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Provide  Human  Computer 
Interface 

Description:  This  function  represents  the  aggregate 
of  all  lower  functions  performed  by  the  Human 
Computer  Interface.  It  is  the  sum  of  the 
sub-functions  Give  Feedback  and  Accept  Input. 
Reference:  1.2 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Provide  ISR  Capabilities 

Description:  This  function  represents  the  aggregate 
of  all  lower  functions  performed  by  the  ISR  MAV 
system.  It  is  the  sum  of  the  sub-functions  Perform 
Ground  Unit  Functions  and  Perform  MAV 

Functions.  It  is  the  top-level  function  for  the 
system. 

Reference:  Top  Level  Function 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Provide  MAV  Airborne 
Communication 

Description:  This  function  represents  the  aggregate 
of  all  lower  functions  performed  by  the  MAV 
Airborne  Communication  sub-system.  It  is  the  sum 
of  the  sub-functions  Transmit  Data,  Receive  MAV 
Directives,  De-Modulate  MAV  Directives,  Accept 
Supplied  Power,  and  Modulate  Data. 

Reference:  2.1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Provide  MAV  Ground 
Communication 

Description:  This  function  represents  the  aggregate 
of  all  lower  functions  performed  by  the  MAV 

Ground  Communication  sub-system.  It  is  the  sum 
of  the  sub-functions  Modulate  MAV  Directives, 
Transmit  MAV  Directives,  De-Modulate  Data,  and 
Receive  Data. 

Reference:  1.5 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Receive  Data 

Description:  See  SV-1  Definition  Table 

Reference:  1.5.4 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Receive  Directives 

Description:  See  SV-1  Definition  Table 

Reference:  1.3.2 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Receive  MAV  Directives 

Description:  See  SV-1  Definition  Table 

Reference:  2.1.2 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Route  Info 

Description:  See  SV-1  Definition  Table 

Reference:  1.4.1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Signal/  Data  Processing 

Description:  This  function  represents  the  aggregate 
of  all  lower  functions  performed  by  the  Signal/ 

Data  Processor  sub-system.  It  is  the  sum  of  the 
sub-functions  Manipulate  data,  Convert/  Route 

Data,  and  Process  Data. 

Reference:  1.1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Take  Flight 

Description:  See  SV-1  Definition  Table 

Reference:  2.2.2 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Transmit  Data 

Description:  See  SV-1  Definition  Table 

Reference:  2.1.1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Transmit  ISR  Info 

Description:  See  SV-1  Definition  Table 

Reference:  1.3.1 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Transmit  MAV  Directives 

Description:  See  SV-1  Definition  Table 

Reference:  1.5.2 

Views:  SV-lb,  SV-lc,  SV-4,  SV-5,  SV-6 

Graphical  Box  Types: 

System  Data  Repository/  Shared  Database 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Processed  Data 

Description:  Repository  of  gathered  and  processed 
data  from  the  air  vehicle’s  payload  sensor.  Data 
from  this  repository  may  be  called  by  the 
manipulate  data  function  to  be  formatted  into 
output  data  at  the  user’s  request.  The  repository  will 
contain  the  images,  videos,  etc.  from  the  sensor  in 
their  storable  format.  Operations  such  as 
re-zooming,  cropping,  image  color  enhancing,  etc. 
would  be  performed  by  the  manipulate  data 
function. 

Within  Reference:  Signal/ Data  Processing,  1.1 

Data  Flow:  Processed  Data 

Function  From:  Process  Data,  1.1.3 

Function  To:  Manipulate  Data,  1.1.1 

Views:  SV-4 

Graphical  Arrow  Types: 

System  Data  Flow 

Commands 

Description:  See  SV-1  Definition  Table  for  Request/ 
Commands,  ISR  Data 

Function  From:  Transmit  MAV  Directives  (1.5.2) 
Function  To:  Receive  MAV  Directives  (2.1.2) 

Views:  SV-lc,  SV-4,  SV-6 

Data  Request 

Description:  This  data  flow  is  a  call  or  request  for 
data  from  the  Processed  Data  repository.  This 
request  will  normally  be  in  response  to  an  Output 
Data  Request  ultimately  from  the  user.  This  data 
request  is  necessary  to  manipulate  the  stored  data  to 
meet  the  user’s  needs. 

Function  From:  Manipulate  Data  (1.1.1) 

Function  To:  Processed  Data  (Data  Repository) 
Views:  SV-4 

Decision  to  Communicate 

Description:  This  data  flow  is  active  decision  by  the 
human  operator  (through  the  Process  Info  function) 
to  relay  information  through  the  Field 
Communication  system. 

Function  From:  Process  Info  (1.4.2) 

Function  To:  Route  Info  (1.4.1) 

Views:  SV-4 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Decision  to  Influence  System 

Description:  This  data  flow  is  active  decision  by  the 
human  operator  (through  the  Process  Info  function) 
to  affect  influence  on  the  system  (e.g.  turn  system 
on,  launch,  recover  MAV,  etc.). 

Function  From:  Process  Info  (1.4.2) 

Function  To:  Influence  System  (1.4.3) 

Views:  SV-4 

Decision  to  Maintain  System 

Description:  This  data  flow  is  active  decision  by  the 
human  operator  (through  the  Process  Info  function) 
to  perform  a  maintenance  action  on  the  system. 
Function  From:  Process  Info  (1.4.2) 

Function  To:  Maintain  System  (1.4.4) 

Views:  SV-4 

Field  Comm  Interface 

Description:  See  SV-1  Definition  Table 

Function  From:  Route  Info  (1.4.1)  and 

De-Modulate  Directives  (1.3.4) 

Function  To:  Modulate  ISR  Information  (1.3.3)  and 
Process  Info  (1.4.2) 

Views:  SV-lc,  SV-4,  SV-6 

Flight  Control  Commands 

Description:  This  data  flow  includes  the  flight 
surfaces  commands  necessary  to  affect  the  flight  of 
the  MAV  air  vehicle.  They  will  be  generated  by  the 
autopilot  processor  in  response  to  a  commanded 
flight  profile. 

Function  From:  Flight  Control  (2.2.1) 

Function  To:  Take  Flight  (2.2.2) 

Views:  SV-4 

Flight  Control/  Position  Data 

Description:  This  data  flow  includes  feedback  of 
what  the  flight  control  function  is  performing  and 
the  position  information  of  the  air  vehicle  as  a  result 
of  processing  the  GPS  satellite  navigation  data. 
Function  From:  Flight  Control  (2.2.1) 

Function  To:  Flight  Data  Protocol  (2.2.3) 

Views:  SV-4 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Flight  Profile 

Description:  This  data  flow  is  the  received  and 
formatted  MAV  directives  that  include  where  and 
how  the  MAV  should  fly.  It  will  contain  desired 
position,  speed,  altitude,  loiter  and  other 
information  required  by  the  flight  controller 
function  to  determine  commands  to  the  flight 
control  surfaces. 

Function  From:  Flight  Data  Protocol  (2.2.3) 

Function  To:  Flight  Control  (2.2.1) 

Views:  SV-4 

Flight  Status  Data 

Description:  This  data  flow  gives  feedback  and 
position  data  to  the  ground  unit  of  the  air  vehicles 
location  and  condition. 

Function  From:  Flight  Data  Protocol  (2.2.3) 

Function  To:  Modulate  Data  (2.1.5) 

Views:  SV-4 

Formatted  Payload  Data 

Description:  This  data  flow  is  the  formatted  and 
packaged  payload  sensor  data  that  the  sensor  has 
gathered. 

Function  From:  Convert  ISR  Data  (2.3.3) 

Function  To:  Payload  Data  Protocol  (2.3.1) 

Views:  SV-4 

Fused  Target  Information 

Description:  See  OV-5  Definition  Table 

Function  From:  Transmit  ISR  Information  (1.3.1) 
Function  To:  Headquarters  and  Strike  Assets 
(External  Systems) 

Views:  OV-5,  OV-7,  SV-lc,  SV-4,  SV-6 

Human  Inputs 

Description:  See  SV-1  Definition  Table  for  Inputs 
Function  From:  Influence  System  (1.4.3) 

Function  To:  Accept  Input  (1.2.2) 

Views:  SV-lc,  SV-4,  SV-6 

Input  Data 

Description:  See  SV-1  Definition  Table  for  Input 

Data 

Function  From:  Accept  Input  (1.2.2) 

Function  To:  Convert/  Route  Data  (1.1.2) 

Views:  SV-lc,  SV-4,  SV-6 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

ISR/  Flight  Status  Data 

Description:  This  data  flow  is  the  combination  of 
both  the  gathered  payload  sensor  data  and  the  flight 
status  of  the  air  vehicle  that  is  sent  to  the  ground 
unit.  It’s  level  of  formatting  and  packaging  is  only 
that  which  would  be  necessary  for  communication 
to  the  ground  unit. 

Function  From:  Transmit  Data  (2.1.1) 

Function  To:  Receive  Data  (1.5.4) 

Views:  SV-lc,  SV-4,  SV-6 

MAV  Directives 

Description:  See  SV-1  Definition  Table 

Function  From:  Convert/  Route  Data  (1.1.2)  and 
De-Modulate  MAV  Directives  (2.1.3) 

Function  To:  Modulate  MAV  Directives  (1.5.1)  and 
Flight  Data  Protocol  (2.2.3) 

Views:  SV-lc,  SV-4,  SV-6 

Modulated  Directives 

Description:  This  data  flow  is  simply  the  directives 
that  are  modulated  for  transmittal  to  the  MAV  from 
the  ground  unit. 

Function  From:  Modulate  MAV  Directives  (1.5.1) 
Function  To:  Transmit  MAV  Directives  (1.5.2) 

Views:  SV-4 

Modulated  ISR  Data 

Description:  This  data  flow  is  simply  the  ISR  info 
that  is  modulated  for  transmittal  to  either 
headquarters  or  the  strike  assets  from  the  ground 
unit. 

Function  From:  Modulate  ISR  Info  (1.3.3) 

Function  To:  Transmit  ISR  Information  (1.3.1) 
Views:  SV-4 

Modulated  ISR/  Flight  Status 
Data 

Description:  This  data  flow  is  simply  the  ISR/ 

Flight  Status  Data  modulated  for  transmittal  to  the 
ground  unit  from  the  MAV. 

Function  From:  Modulate  Data  (2.1.5) 

Function  To:  Transmit  Data  (2.1.1) 

Views:  SV-4 

Modulated  MAV  Directives 

Description:  This  data  flow  is  simply  the  MAV 
directives  modulated  for  transmittal  from  the  MAV 
communications  system  to  the  air  vehicle  flight 
control. 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Function  From:  Receive  MAV  Directives  (2. 1 .2) 
Function  To:  De-Modulate  MAV  Directives  (2.1.3) 
Views:  SV-4 

Modulated  Payload  Data 

Description: 

Function  From:  Receive  Data  (1.5.4) 

Function  To:  De-Modulate  Data  (1.5.3) 

Views:  SV-4 

Modulated  Taskings 

Description:  This  data  flow  is  the  taskings 
modulated  for  transmittal  from  Headquarters  or 

Strike  Assets  to  the  Human  Operator. 

Function  From:  Receive  Directives  (1.3.2) 

Function  To:  De-Modulate  Directives  (1.3.4) 

Views:  SV-4 

Navigation  Data 

Description:  See  OV-1  Definition  Table 

Function  From:  GPS  Satellites  (External  System) 
Function  To:  Flight  Control  (2.2.1) 

Views:  OV-1,  OV-2,  OV-3,  OV-5,  OV-7,  SV-lc, 

SV-4,  SV-6 

Output  Data 

Description:  See  SV-1  Definition  Table  for 

Feedback 

Function  From:  Manipulate  Data  (1.1.1)  and 

Convert/  Route  Data  (1.1.2) 

Function  To:  Convert/  Route  Data  (1.1.2)  and  Give 
Feedback  (1.2.1) 

Views:  SV-lc,  SV-4,  SV-6 

Output  Data  Request 

Description:  This  data  flow  is  a  call  or  request  for 
data  to  be  manipulated.  It  can  also  carry  commands 
on  how  the  data  is  to  be  manipulated  (e.g.  resize, 
zoom,  etc.). 

Function  From:  Convert/  Route  Data  (1.1.2) 

Function  To:  Manipulate  Data  (1.1.1) 

Views:  SV-4 

Payload  Data 

Description:  See  SV-1  Definition  Table 

Function  From:  Payload  Data  Protocol  (2.3.1) 
Function  To:  Modulate  Data  (2.1.5) 

Views:  OV-5,  OV-7,  SV-lc,  SV-4,  SV-6 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Payload/  Flight  Status  Data 

Description:  This  data  flow  includes  ah  information 
transmitted  from  the  MAV  to  the  ground  unit.  It  is 
unprocessed  information  to  be  transformed  and 
used  by  the  ground  unit. 

Function  From:  De-Modulate  Data  (1.5.3) 

Function  To:  Convert/  Route  Data  (1.1.2) 

Views:  OV-7,  SV-lc,  SV-4,  SV-6 

Platform  Interface 

Description:  See  SV-1  Definition  Table 

Function  From:  Influence  System  (1.4.3)  and 
Maintain  System  (1.4.4) 

Function  To:  Take  Flight  (2.2.2) 

Views:  SV-lc,  SV-4,  SV-6 

Power 

Description:  See  SV-1  Definition  Table 

Function  From:  Power  Source  (2.2.4) 

Function  To:  Enable  ISR  Capability  (2.3.2)  and 
Accept  Supplied  Power  (2.1.4) 

Views:  SV-lc,  SV-4,  SV-6 

Processed  Data 

Description:  This  data  flow  is  the  processed, 
formatted,  and  packaged  data  from  the  MAV. 

Images  and/or  videos  are  saved  in  acceptable  file 
formats. 

Function  From:  Process  Data  (1.1.3)  and  Processed 
Data  (Data  Repository) 

Function  To:  Processed  Data  (Data  Repository)  and 
Manipulate  Data  (1.1.1) 

Views:  SV-4 

Raw  Payload  Data 

Description:  This  data  flow  is  the  basic  electronic 
signals  generated  by  the  payload  sensor  in  response 
to  the  target  of  its  sensor  gathering  function. 

Function  From:  Enable  ISR  Capability  (2.3.2) 
Function  To:  Convert  ISR  Data  (2.3.3) 

Views:  SV-4 

Repair/  Fault  Status 

Description:  See  OV-5  Definition  Table  for  System 
Repair  Status 

Function  From:  Maintain  System  (1.4.4) 

Function  To:  Process  Info  (1.4.2) 

Views:  OV-5,  OV-7,  SV-4 

System  Status 

Description:  See  OV-7  Definition  Table 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Function  From:  Influence  System  (1.4.3) 

Function  To:  Process  Info  (1.4.2) 

Views:  OV-7,  SV-4 

Tasking  s 

Description:  See  OV-5  Definition  Table 

Function  From:  Headquarters  and  Strike  Assets 
(External  Systems) 

Function  To:  Receive  Directives  (1.3.2) 

Views:  OV-5,  OV-7,  SV-lc,  SV-4,  SV-6 

Unprocessed  Data 

Description:  This  data  flow  is  the  data  that  has  been 
received  by  the  ground  unit  communications  system 
from  the  MAV. 

Function  From:  Convert/  Route  Data  (1.1.2) 

Function  To:  Process  Data  (1.1.3) 

Views:  SV-4 

User  Feedback 

Description:  See  SV-1  Definition  Table 

Function  From:  Give  Feedback  (1.2.1) 

Function  To:  Process  Info  (1.4.2) 

Views:  SV-lc,  SV-4,  SV-6 

Functional  Decomposition 

Super  Function 

Sub-Functions 

Provide  ISR  Capabilities 

1 .  Perform  Ground  Unit  Functions 

2.  Perform  MAV  Functions 

1.  Perform  Ground  Unit 

1 . 1  Signal/  Data  Processing 

Functions 

1.2  Provide  Human  Computer  Interface 

1.3  Provide  Field  Communication 

1.4  Perform  Human  Operator  Functions 

1.5  Provide  MAV  Ground  Communication 

2.  Perform  MAV  Functions 

2.1  Provide  MAV  Airborne  Communication 

2.2  Perform  Air  Vehicle  Functions 

2.3  Perform  Payload/Sensor  Functions 

1.1  Signal/  Data  Processing 

1.1.1  Manipulate  Data 

1.1.2  Convert/  Route  Data 

1.1.3  Process  Data 

1.2  Provide  Human  Computer 

1.2.1  Give  Feedback 

Interface 

1.2.2  Accept  Input 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

1.3  Provide  Field 

1.3.1  Transmit  ISR  Information 

Communication 

1.3.2  Receive  Directives 

1.3.3  Modulate  ISR  Information 

1.3.4  De-Modulate  Directives 

1.4  Perform  Human  Operator 

1.4.1  Route  Info 

Functions 

1.4.2  Process  Info 

1.4.3  Influence  System 

1 .4.4  Maintain  System 

1.5  Provide  MAV  Ground 

1.5.1  Modulate  MAV  Directives 

Communication 

1.5.2  Transmit  MAV  Directives 

1.5.3  De-Modulate  Data 

1.5.4  Receive  Data 

2.1  Provide  Airborne 

2.1.1  Transmit  Data 

Communication 

2.1.2  Receive  MAV  Directives 

2.1.3  De-Modulate  MAV  Directives 

2.1.4  Accept  Supplied  Power 

2.1.5  Modulate  Data 

2.2  Perform  Air  Vehicle 

2.2.1  Flight  Control 

Functions 

2.2.2  Take  Flight 

2.2.3  Flight  Data  Protocol 

2.2.4  Power  Source 

2.3  Perform  Payload/  Sensor 

2.3.1  Payload  Data  Protocol 

Functions 

2.3.2  Enable  ISR  Capability 

2.3.3  Convert  ISR  Data 
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Figure  L.  1  Functional  Decomposition 
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Figure  L.2  SV-4  Context  Diagram 
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Figure  L.3  SV-4  Level  0  Diagram 
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Figure  L.4  SV-4  Level  1  Diagram 
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Figure  L.5  SV-4  Level  1-1  Diagram 
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Figure  L.6  SV-4  Level  1-2  Diagram 
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Figure  L.7  SV-4  Level  1-3  Diagram 
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Figure  L.8  SV-4  Level  1-4  Diagram 
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Figure  L.9  SV-4  Level  1-5  Diagram 
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Figure  L.  10  SV-4  Level  2  Diagram 
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Figure  L.  1 1  SV-4  Level  2- 1  Diagram 
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Figure  L.  12  SV-4  Level  2-2  Diagram 
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Figure  L.  13  SV-4  Level  2-3  Diagram 
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Appendix  M.  MAV  SV-5 


Table  M.l  -  AY-2  Integrated  Dictionary 


Entities,  Attributes,  and 
Relationships 

Description 

Reference  Types 

Capabilities 

See  OV-5  Definition  Table 

Systems 

See  SV-1  Definition  Table 

Operational  Activities 

See  OV-5  Definition  Table 

System  Functions 

See  SV-1  Definition  Table 

Relationships 

Supporting  System  Function 

Operational  Activity  for  a  Capability 

Accept  Input 

Operational  Activity:  Process  Information 

System  Name:  Human  Computer  Interface 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Accept  Supplied  Power 

Operational  Activity:  Provides  Flight  Controls, 
Enables  Sensor  Package 

System  Name:  MAV  Airborne  Communication 
System 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Convert/Route  Data 

Operational  Activity:  Provides  Vehicle  Control  and 
Communication,  Initialize  MAV,  Calibrate  MAV, 
Upload  Mission  Profile 

System  Name:  Signal/Data  Processor 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Convert  ISR  Data 

Operational  Activity:  Enables  Sensor  Package 
System  Name:  Payload  or  Sensor  Package 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

De-Modulate  Data 

Operational  Activity:  Provides  Vehicle  Control  and 
Communication 

System  Name:  MAV  Ground  Communication 

System 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  FAD 

Support  Status  Code:  Application  Specific 

De-Modulate  Directives 

Operational  Activity:  Process  Information 

System  Name:  Field  Communication  System 
Capability  Name:  Perform  Reconnaissance,  BDI, 
and  FAD 

Support  Status  Code:  Application  Specific 

De-Modulate  MAV  Directives 

Operational  Activity:  Provides  Flight  Controls, 
Enables  Sensor  Package 

System  Name:  MAV  Airborne  Communication 
System 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  FAD 

Support  Status  Code:  Application  Specific 

Enable  ISR  Capability 

Operational  Activity:  Enables  Sensor  Package 
System  Name:  Payload  or  Sensor  Package 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  FAD 

Support  Status  Code:  Application  Specific 

Flight  Control 

Operational  Activity:  Provides  Flight  Controls, 
Calculate  Flight  Plan  to  Fanding  Zone,  Fly  to 
Fanding  Zone,  Perform  Fanding  Sequence 

System  Name:  Air  Vehicle 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  FAD 

Support  Status  Code:  Application  Specific 

Flight  Data  Protocol 

Operational  Activity:  Provides  Flight  Controls 
System  Name:  Air  Vehicle 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  FAD 

Support  Status  Code:  Application  Specific 

Give  Feedback 

Operational  Activity:  Process  Information 

System  Name:  Human  Computer  Interface 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  FAD 

Support  Status  Code:  Application  Specific 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Influence  System 

Operational  Activity:  Initialize  MAV,  Calibrate 

MAV,  Upload  Mission  Profile,  Launch  MAV, 

Recover  MAV 

System  Name:  Human  Operator 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Maintain  System 

Operational  Activity:  Provide  Field  Level 
Maintenance 

System  Name:  Human  Operator 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Manipulate  Data 

Operational  Activity:  Provides  Vehicle  Control  and 
Communication,  Initialize  MAV,  Calibrate  MAV, 
Upload  Mission  Profile 

System  Name:  Signal/Data  Processor 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Modulate  Data 

Operational  Activity:  Provides  Flight  Controls, 
Enables  Sensor  Package 

System  Name:  MAV  Airborne  Communication 
System 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Modulate  ISR  Information 

Operational  Activity:  Process  Information 

System  Name:  Field  Communication  System 
Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Modulate  MAY  Directives 

Operational  Activity:  Provides  Vehicle  Control  and 
Communication,  Calibrate  MAV 

System  Name:  MAV  Ground  Communication 

System 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Support  Status  Code:  Application  Specific 

Payload  Data  Protocol 

Operational  Activity:  Enables  Sensor  Package 
System  Name:  Payload  or  Sensor  Package 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Power  Source 

Operational  Activity:  Provides  Flight  Vehicle 

System  Name:  Air  Vehicle 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Process  Data 

Operational  Activity:  Provides  Vehicle  Control  and 
Communication,  Initialize  MAV,  Calibrate  MAV, 
Upload  Mission  Profile 

System  Name:  Signal/Data  Processor 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Process  Info 

Operational  Activity:  Process  Information 

System  Name:  Human  Operator 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Receive  Data 

Operational  Activity:  Provides  Vehicle  Control  and 
Communication 

System  Name:  MAV  Ground  Communication 

System 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Receive  Directives 

Operational  Activity:  Process  Information 

System  Name:  Field  Communication  System 
Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Receive  MAY  Directives 

Operational  Activity:  Provides  Flight  Controls, 
Enables  Sensor  Package 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

System  Name:  MAV  Airborne  Communication 
System 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Route  Info 

Operational  Activity:  Process  Information 

System  Name:  Human  Operator 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Take  Flight 

Operational  Activity:  Provides  Flight  Vehicle,  Fly 
to  Landing  Zone,  Perform  Landing  Sequence 

System  Name:  Air  Vehicle 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Transmit  Data 

Operational  Activity:  Provides  Flight  Controls, 
Enables  Sensor  Package 

System  Name:  MAV  Airborne  Communication 
System 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Transmit  ISR  Information 

Operational  Activity:  Process  Information 

System  Name:  Field  Communication  System 
Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Transmit  MAV  Directives 

Operational  Activity:  Provides  Vehicle  Control  and 
Communication,  Calibrate  MAV 

System  Name:  MAV  Ground  Communication 

System 

Capability  Name:  Perform  Reconnaissance,  BDI, 
and  LAD 

Support  Status  Code:  Application  Specific 

Implementing  System 
Function 

Operational  Activity 

Accept  Input 

Process  Information 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Accept  Supplied  Power 

Provides  Flight  Controls,  Enables  Sensor  Package 

Convert/Route  Data 

Provides  Vehicle  Control  and  Communication, 
Initialize  MAV,  Calibrate  MAV,  Upload  Mission 
Profile 

Convert  ISR  Data 

Enables  Sensor  Package 

De-Modulate  Data 

Provides  Vehicle  Control  and  Communication 

De-Modulate  Directives 

Process  Information 

De-Modulate  MAV  Directives 

Provides  Flight  Controls,  Enables  Sensor  Package 

Enable  ISR  Capability 

Enables  Sensor  Package 

Flight  Control 

Provides  Flight  Controls,  Calculate  Flight  Plan  to 
Fanding  Zone,  Fly  to  Fanding  Zone,  Perform 
Fanding  Sequence 

Flight  Data  Protocol 

Provides  Flight  Controls 

Give  Feedback 

Process  Information 

Influence  System 

Initialize  MAV,  Calibrate  MAV,  Upload  Mission 
Profile,  Faunch  MAV,  Recover  MAV 

Maintain  System 

Provide  Field  Fevel  Maintenance 

Manipulate  Data 

Provides  Vehicle  Control  and  Communication, 
Initialize  MAV,  Calibrate  MAV,  Upload  Mission 
Profile 

Modulate  Data 

Provides  Flight  Controls,  Enables  Sensor  Package 

Modulate  ISR  Information 

Process  Information 

Modulate  MAV  Directives 

Provides  Vehicle  Control  and  Communication, 
Calibrate  MAV 

Payload  Data  Protocol 

Enables  Sensor  Package 

Power  Source 

Provides  Flight  Vehicle 

Process  Data 

Provides  Vehicle  Control  and  Communication, 
Initialize  MAV,  Calibrate  MAV,  Upload  Mission 
Profile 

Process  Info 

Process  Information 

Receive  Data 

Provides  Vehicle  Control  and  Communication 

Receive  Directives 

Process  Information 

Receive  MAV  Directives 

Provides  Flight  Controls,  Enables  Sensor  Package 

Route  Info 

Process  Information 

Take  Flight 

Provides  Flight  Vehicle,  Fly  to  Fanding  Zone, 
Perform  Fanding  Sequence 

Transmit  Data 

Provides  Flight  Controls,  Enables  Sensor  Package 

Continued  on  next  page 
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Entities,  Attributes,  and 
Relationships 

Description 

Transmit  ISR  Information 

Process  Information 

Transmit  MAV  Directives 

Provides  Vehicle  Control  and  Communication, 
Calibrate  MAV 

Figure  M.l  SV-5  Operational  Activity  to  System  Functions  Traceability  Matrix  1 
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Figure  M.2  SV-5  Operational  Activity  to  System  Functions  Traceability  Matrix  2 
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Appendix  N.  MAV  SV-6 

As  outlined  in  Section  3.2.3,  the  SV-6  is  a  matrix  with  a  set  of  rows  and  columns 
where  their  intersections  contain  interface  information.  The  rows  contain  all  information 
contained  within  a  particular  interface  exchange.  Since  the  relationship  between  system 
interfaces  and  system  data  exchanges  are  one-to-many  they  are  categorized  first  by 
the  system  interface  name  shown  in  all  versions  of  the  SV-1  and  then  by  the  system 
data  exchange  name  which  can  be  SV-6  unique  but  in  this  case  correlates  to  the  OV-3s 
information  exchange  names.  The  columns  show  specific  information  based  on  the 
columns  heading.  Many  times,  the  column  headings  are  tailored  to  the  specific  system 
type  that  is  being  modeled.  A  template  for  a  highly  complex,  secure,  and  detailed 
communication  system  may  have  many  extraneous  columns  for  a  simpler  system  with 
fewer  interfaces.  The  tailored  list  below  is  the  column  headings  with  their  meanings 
as  defined  by  DoDAF  [24].  The  columns  outside  the  scope  of  this  initial  baseline 
architecture  have  been  marked  Left  Blank.  This  research  will  still  show  these  empty 
columns  in  order  to  allow  for  future  detailed  research.  Following  the  column  definitions 
are  the  SV-6  matrix  figures  completed  for  the  Baseline  ISR  MAV. 


Row  ID:  Contains  a  unique  row  number  for  each  row  and  is  used  for  easier 
referencing  (instead  of  having  to  recite  the  system  data  exchange  name). 

System  Interface  Name:  Identifies  the  system  interface  as  shown  in  the  SV-1 
system  interface  description  diagram  that  carries  the  system  data  exchange. 

System  Data  Exchange  Name:  Name  of  the  system  data  exchange,  based  on  the 
relevant  operational  needline,  system  interface,  and  information  element.  This 
research  will  correlate  this  column  with  the  information  exchange  name  in  the  OV-3 
matrix. 

Data  Element  Name  and  ID:  Name  of  the  system  data  element,  primarily  based  on 
the  SV-4  system  data  flow  and  can  correlate  to  the  OV-3  information  element.  The 
MAV  baseline  architecture  will  correlate  this  column  with  the  OV-3  information 
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element,  which  ends  up  mapping  back  to  the  OV-5  and  OV-7  diagrams. 


Content:  The  system  data  that  is  carried  by  the  exchange. 

Format  Type:  Application  level  format  (e.g.,  XML/DTD,  EDI,  ASCII  Text)  with 
parameters  and  options  used,  or  other  relevant  protocol.  Left  Blank 

Media  Type:  Type  of  media.  Left  Blank 

Accuracy:  Description  of  the  degree  to  which  the  system  data  conforms  to  actual 
fact  as  required  by  the  system  or  system  function.  Left  Blank 

Units  of  Measurement:  Units  used  for  system  data.  Left  Blank 

Data  Standard:  An  example  is  DoD  XML  Registry,  can  reference  TV-1  or  TV-2 
definition  tables  if  produced  (this  research  does  not  produce  any  TV’s).  Left  Blank 

Sending  System  Name:  Name  of  the  system  from  the  SV-1  that  produces  the 
system  data. 

Sending  System  Function  Name:  The  name  of  the  system  function,  as  shown  in 
the  SV-1,  producing  the  system  data. 

Receiving  System  Name:  Name  of  the  system  from  the  SV-1  that  consumes  the 
system  data. 

Receiving  System  Function  Name:  The  name  of  the  system  function,  as  shown  in 
the  SV-1,  consuming  the  system  data. 

Transaction  Type:  Descriptive  field  that  identifies  the  type  of  exchange. 

Triggering  Event:  Brief  textual  description  of  the  event  that  triggers  the  system 
data  exchange  as  shown  in  the  SV-10.  If  triggering  events  are  not  included  in  the 
SV-10  or  no  SV-10  exists  (in  this  case  none  exists)  then  this  column  is  not  required 
however  an  example  of  such  a  event  can  be  given  as  the  case  with  this  research. 

Interoperability  Level  Required  (from  C4ISR  WG):  Level  of  Information 
Systems  Interoperability  (LISI),  or  other  interoperability  measure.  This  research 
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used  the  C4ISR  Working  Groups  [10]  interoperability  levels.  There  are  5  possible 
levels  of  interoperability  an  information  exchange  can  have,  numbered  0  to  4.  Level 
0  is  termed  the  Isolated  Level  and  consists  of  manual  access  control  procedures, 
manual  infrastructure  and  private  data.  Level  1  is  termed  the  Connected  Level 
and  consists  of  a  security  profile,  two  or  one  way  infrastructure,  and  basic  data 
formats.  Level  2  is  termed  the  Functional  Level  and  consists  of  a  common  operating 
environment,  a  local  area  network  (LAN)  infrastructure,  program  models,  and 
advanced  data  formats.  Level  3  is  termed  the  Domain  Level  and  consists  of 
domain  procedures,  a  wide  area  network  (WAN),  database  management  system 
(DBMS),  and  domain  models.  Level  4  consists  of  enterprise  procedures  (DoD, 
Multi-National),  multiple  dimensional  topologies,  and  cross  enterprise  models. 

Criticality:  The  criticality  assessment  of  the  information  being  exchanged  in 
relationship  of  the  mission  being  performed,  meaning  how  essential  is  it  to  the 
overall  mission  or  capability. 

Periodicity:  Frequency  of  system  data  exchange  transmission,  may  be  an  average 
or  worst  case  estimate  and  can  include  conditions. 

Timeliness:  How  much  delay  this  system  data  can  tolerate  and  still  be  relevant  to 
the  receiving  system.  This  research  uses  in  minutes  and  in  seconds  to  state  the  order 
of  measurement  to  be  used. 

Throughput:  Bits  or  bytes  per  time  period,  may  be  expressed  in  terms  of  maximum 
or  average  throughput  required.  Left  Blank 

Size:  Size  of  system  data.  Left  Blank 

Access  Control:  The  class  of  mechanisms  used  to  ensure  only  those  authorized 
can  access  a  specific  system  data  element.  Left  Blank 

Availability:  The  relative  level  of  effort  required  to  be  expended  to  ensure  that  the 
system  data  can  be  accessed.  Left  Blank 

Confidentiality:  The  kind  of  protection  required  for  system  data  to  prevent 
unintended  disclosure.  Left  Blank 

Dissemination  Control:  The  kind  of  restrictions  on  receivers  of  system  data  based 
on  sensitivity  of  system  data.  Left  Blank 
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Integrity:  The  kind  of  requirement  for  checks  that  the  content  of  the  system  data 
element  has  not  been  altered.  Left  Blank 

Non-Repudiation  Producer:  The  requirements  for  unassailable  knowledge  that 
the  system  data  received  was  produced  by  the  stated  source.  Left  Blank 

Non-Repudiation  Consumer:  The  requirements  for  unassailable  knowledge  that 
the  system  data  sent  was  consumed  by  the  intended  recipient.  Left  Blank 

Protection  (Type,  Name,  Duration,  Date):  The  name  for  the  type  of  protection, 
the  code  that  represents  how  long  the  system  data  must  be  safeguarded,  and  the 
calendar  date  on  which  the  designated  level  of  safeguarding  discontinues  for  a 
specific  system  data  element.  Left  Blank 

Classification:  Classification  code  for  the  system  data  element.  Left  Blank 

Classification  Caveat:  A  set  of  restrictions  on  system  data  of  a  specific  classi¬ 
fication.  Supplements  a  security  classification  with  system  data  on  access, 
dissemination,  and  other  types  of  restrictions.  Left  Blank 

Releasability:  The  code  that  represents  the  kind  of  controls  required  for  further 
dissemination  of  system  data.  Left  Blank 

Security  Standard:  Defined  by  completed  TV  architectural  views.  Left  Blank 
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